This paper presents a structured IT security plan for a small corporation operating a network of thirty computers and three servers running web, email, and database applications. Using the Open Systems Interconnect (OSI) Model as a guiding framework, the paper analyzes security vulnerabilities at each network layer and proposes remediation strategies including VPN deployment, SSL standardization, and rules-based email filtering. The plan is organized into three implementation phases: baseline security auditing and benchmarking, application-level security upgrades, and the development of enterprise-wide security policies. The paper also defines project deliverables for each phase and recommends the creation of a Director of Security role to sustain long-term compliance and competitiveness.
The paper demonstrates applied framework analysis: it selects an established theoretical model (the OSI Model) and systematically applies it as a diagnostic lens across all seven network layers, producing layer-specific security recommendations. This technique shows how abstract frameworks can be operationalized to generate concrete, context-specific guidance — a skill central to applied IT and information systems coursework.
The paper opens with a problem statement and framework justification, then conducts a layer-by-layer OSI analysis. It transitions into a systems analysis rationale, followed by three formally numbered goals with supporting objectives. A phased project plan with explicit timelines and deliverables occupies the final sections, concluding with a staffing recommendation. This structure moves logically from diagnosis to strategy to execution, reflecting a standard IT proposal format.
Small corporations often have to deal with many conflicting, time-consuming IT priorities to keep their businesses making progress and profits. Yet the absence of an IT Security Plan can seriously cripple any company's performance and profitability, and is one of the leading causes of smaller corporations failing (Gupta & Hammond, 2005). The intent of this project proposal is to define an IT Security Plan for a small business network of thirty computers and three servers running web-based applications, an email system, and a database application server. Email systems in smaller corporations are particularly in need of continual security upgrades, as they often pose a significant security risk (Zambroski, 2006). In addition to inadequate email security, many small corporations also lack meaningful metrics around overall security system performance (Frankland, 2008).
Given these significant gaps in security coverage, there is a clear need to manage the IT Security Plan and its implementation using a proven framework.
This proposal relies on the Open Systems Interconnect (OSI) Model, defined by the International Organization for Standardization (ISO). The purpose of the ISO is to ensure a high level of interoperability and integration between systems, with a specific focus on the flow of data between systems. The OSI Model is an excellent framework for evaluating the security of networks. It is designed to provide a logical grouping of network functions while taking into account the physical connections required to make a network effective. This model is ideally suited for evaluating network security because its upper layers define the logical connections and process workflows where the majority of security planning and execution are necessary to alleviate threats.
An analysis of the security considerations for a small corporation's network of thirty computers and three servers — running web, email, and database applications — within the framework of each OSI Model layer is provided below.
The Physical Layer defines the standards relating to the physical medium of the network, such as cables, unshielded twisted pairs (UTP), 10BaseT connections, and other hardware. The primary security risk at this layer is that packets sent over the network via the TCP/IP protocol can be intercepted by devices (often called "packet sniffers"), allowing messages to be read and data stolen (Gupta & Hammond, 2005). For small corporations, this threat often goes undetected and cannot easily be stopped with firewalls or DMZ-based software or hybrid software-hardware security platforms. Physical security at this level is therefore critical. Using Virtual Private Networks (VPNs) and advanced IPSec-based security makes intercepting and interpreting packets significantly more difficult (Rowan, 2007), and as a result VPNs have become a predominant security tool.
The Data Link Layer interprets data packets and defines the transfer and reception of data on the network, managing data frames between the network layer and the physical layer. It creates data frames and delivers them to the network layer on the sending side, while interpreting and decoding packets down to bits on the receiving side. Hackers specifically target this layer for the vulnerabilities of the Logical Link Control (LLC) function, which handles error correction, and the Media Access Control (MAC) sublayer, which enables point-to-point connections over a network. The MAC layer is especially vulnerable to packet redirection, and spoofing or impersonation attacks frequently attempt to penetrate and control it (Ciampa, 2005). Because the MAC layer encompasses both the physical and logical connections of a network, security threats at this layer must be mitigated using DMZ-based security applications and firewalls (Loew, Stengel, Bleimann, & McDonald, 1999).
The Network Layer (third level) integrates and secures the Internet Protocol (IP) within the OSI Model protocol stack. Its most important function is deconstructing large IP-based packets for transmission across the network. This layer works in data units called datagrams and is susceptible to IP traffic rerouting based on IP address emulation and impersonation, as well as unauthorized IP-based data transfer requests (Gupta & Hammond, 2005).
The Transport Layer (fourth level) is where actual data transmission occurs. It houses the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), both of which are protected through firewalls (Ciampa, 2005) and are also relied upon for secure VPN connections for remote networks (Rowan, 2007).
The Session Layer (fifth level) manages the establishment of session connections between wireless and WiFi networks (Loo, 2008), Local Area Networks (LANs), and Wide Area Networks (WANs). As an enabler of network traffic, this layer defines and manages bidirectional versus unidirectional protocols, the extent to which TCP/IP relies on Error Correction Coding (ECC), and the use of Cyclic Redundancy Check (CRC) error checking. It also relies on the Session Protocol Data Unit (SPDU) to validate, secure, and release specific connections for greater security (Cisco Tutorial, 2007). For a small corporation, maintaining consistent ECC and CRC checks is critical at this layer, as are protocol-based security audits across the network (Gupta & Hammond, 2005).
The Presentation Layer (sixth level) acts as a converter of information from the lower layers, managing message transmission by validating message syntax, coordinating traffic from the lower layers, and defining security authentication logic between originating and destination systems. This layer is typically protected through multiple approaches, including firewalls capable of detecting impersonated or invalid IP addresses and rules-based authentication on advanced firewalls and security applications (Gupta & Hammond, 2005).
The Application Layer (seventh level) serves as the coordination point for TCP/IP-based commands, web browsers, and office automation applications that rely on XML messaging and Internet connections. This layer is commonly protected through VPN-based connections for shared applications, with IPSec used for point-to-point security and SSL support for broader web-based application deployments (Rowan, 2007). Security at this layer is increasingly focused on shared or web-based applications as a result of the widespread adoption of XML and AJAX-based architectures.
In evaluating the IT Security Plan for a small privately held corporation, several significant lessons can be learned from other organizations' implementations. First, leading organizations adopt a broad, enterprise-wide approach to defining security strategies — covering all web content, VPN access points, internal databases accessible via authentication, and access to accounting and financial systems (Loew et al., 1999). These organizations rely on expert-level analysts to evaluate market trends and provide prescriptive guidance, and they likewise require secured VPN and SSL connections throughout. The use of SSL as a means of ensuring the security and verifiability of traffic over VPN connections is a best practice that scales well to meet the needs of increasingly mobile workforces (Rowan, 2007). Both the overarching security strategy and the creation of a consistent VPN and remote access standard are critical for protecting intellectual property.
The need for higher levels of security across the corporation's network is accentuated by the fact that the majority of PCs in use today are laptops relying on WiFi connections throughout the organization. The three servers running the website, email system, and database application will also need specific analysis of their existing security configurations based on the options selected during installation. Operating system-level security must first be evaluated to confirm that firewall options were properly configured. All of these factors must be addressed in an initial security audit that establishes the baseline for ongoing security performance evaluation (Westcott, 2007).
Second, all specific connection points throughout the network — including the WiFi infrastructure — must be audited and tested for their existing security levels (Loo, 2008). Third, VPN deployments and protocol selections must be audited (Westcott, 2007) to evaluate the relative performance of IPSec versus SSL on overall network performance (Rowan, 2007). Many smaller corporations vacillate between these two standards for wireless connections. The table below captures the key technical differences.
Table 1: Technical Analysis of Differences Between IPSec and SSL
Topology: IPSec is primarily used for site-to-site VPNs in hub-and-spoke configurations. SSL is designed for remote-access VPN scenarios.
Security: IPSec authenticates sessions via digital certificates or preshared keys and drops non-conforming packets. SSL also authenticates via digital certificates and drops packets when a fatal alert is received.
Confidentiality: IPSec uses a flexible suite of encryption and tunneling mechanisms at the IP network layer. SSL encrypts traffic using public key infrastructure (PKI).
QoS and SLAs: IPSec VPNs can be configured to preserve packet classification for QoS within a tunnel, though QoS is not addressed directly. SSL deployments are unaffected by QoS or SLA requirements, as service provider network traffic is unaware of SSL traffic.
Scalability: IPSec provides acceptable scalability in most hub-and-spoke deployments but requires key management support for large meshed VPNs exceeding 10,000 users. SSL scalability is entirely dependent on network traffic and is unaffected by service provider infrastructure.
Management and Provisioning: IPSec supports site-to-site deployments and reduces operational expense through centralized network-level provisioning. SSL does not apply in site-to-site scenarios and service provider traffic does not see SSL traffic.
VPN Client: IPSec requires a dedicated client for client-initiated deployments. SSL relies on a standard web browser to complete sessions.
Wireless: IPSec is not easily accomplished in wireless environments, as it relies on point-to-point connections. SSL supports QoS, non-QoS, and enterprise-wide wireless connectivity.
Sources: (Hickman, 2007; Rowan, 2007; OpenReach, 2002)
As many internal networks are now VPN-based due to the proliferation of overlapping wireless networks in office and metropolitan areas, securing connections even within a company's own premises has become essential (Rowan, 2007). SSL-based security technologies for connecting WiFi-enabled printers and remote storage equipment must also be included in the initial security audit (Westcott, 2007).
With these audits defined, the next step is establishing security-based performance metrics (Frankland, 2008). Benchmarking security levels will give the corporation an opportunity to observe gradual progress over time, evaluate the impact of security efforts on system stability and uptime, and track, log, and analyze patterns in external threats. This threat analytics capability is also critically important for developing a corporation-wide security plan (Loew et al., 1999).
A third rationale — alongside benchmarking and developing a corporate-wide strategy — is the need to more effectively manage application-level threats. This is most prevalent in email systems (Zambroski, 2006), where viruses arrive via inbound email undetected by firewalls and other measures. Creating auditability within email systems (Westcott, 2007) is critically important to ensure proper use guidelines are followed and that the corporation does not expose itself to lawsuits or server-wide virus infections via infected documents and emails. A continual virus scanning strategy and a roadmap of ongoing updates are therefore essential (Lin, Chen, Lin, & Lai, 2008).
The security implications of unsecured WiFi networks extend well beyond corporate espionage. One widely cited example is how the terrorists responsible for the 2008 Mumbai attacks hacked into hotel networks to identify rooms occupied by American and British visitors (Shastri, 2009). Wireless networks around the hotel also lacked sufficient security to monitor the attackers' communications during the siege. There are also documented instances of companies' financial data being stolen over WiFi networks due to the absence of security audits validating coverage strength (Rowan, 2007). All of these factors — WiFi security, server and network stabilization, security audits, and ongoing analysis — must be part of a broader security upgrade strategy.
You’re 42% through this paper. Sign up to read the remaining 3 sections.
Sign Up Now — Instant Access Already a member? Log inAlways verify citation format against your institution’s current style guide requirements.