Information Technology Capstone Project Part IV: Developing Network Policies and Strategies

Scenario

In this particular part of the project, there is the recognition of a need to develop a top-notch security plan/policy to handle the various amounts of issues that pertain to network vulnerability.

Oppenheimer (2010) stated that security strategies or rather a policy is fundamental, yet complex in network design. The design of networks is challenged by the overwhelming amount of security risks that often accompany a network design infrastructure. Prior to a discussion on risks, it is important to identify network assets, which can include host networks, various devices that utilize the Internet devices, and data warehousing that traverses the network (Oppenheimer, 2010). Additionally, there is a need to understand what a risk is which "can range from hostile intruders to untrained users who download Internet applications that have viruses. Hostile intruders can steal data, change data, and cause service to be denied to genuine users. [There are] also denial of service attacks, which have become [more and more] common in the past few years" (Oppenheimer, 2010). The basis then of a security policy is to prevent and protect from these notable issues. In the company's assessment of the need for such a policy, cost is a must as it is important to ensure that in the context of a policy creation that losses and risks are expressed in said implementation. While there is an appearance that cost is no option, companies and corporations need to set boundaries for the information technology teams pertaining to costs associated with protecting from security risks.

Oppenheimer (2010) continued to relay that companies and corporations that implement a security policy have to make tradeoffs "between security goals and goals for affordability, usability, performance and availability. Security also adds to the amount of management work because [of] user login IDs, passwords and audit logs maintenance. Security also affects network performance as features such as packet filters and data encryption consume CPU power and memory on hosts, routers and servers" (Oppenheimer, 2010). Additionally, it has often been recommended that companies establish a DMZ. The purpose of a DMZ is to create an additional layer of security within a physical network infrastructure of a company (DSLReports, 1999). Irrespective of such concerns that security has, it is essential for such a policy to be created that both solidifies the company’s dedication to safeguarding the necessary elements of the company while making the needed tradeoffs to a certain extent. 

Security Policy Understanding

Per RFC 2196, Site Security Handbook the security policy is a formalized statement of rules that people who have access to a company's technological and informational assets must adhere to (IETF, 1997). The security policy provides managers, users as well as technical staff of their obligations to protect these assets. The development of the policy is the task of management, more so senior, with input from both engineers and network designers. Nussbaum (2012) stressed the importance of companies understanding the principles of security policies by considering CIA, or confidentiality, integrity and availability. These are necessary facets to a security policy. Confidentiality is defined as ensuring that the systems only permit access to individuals who are authorized to see certain information of a private, proprietary and other sensitive nature. In utilizing what is known as the authentication principle, password policies and other authentication mechanisms can be established. In addition to this, integrity is defined as protecting the system from any kind of modification or subtle manipulation of sensitive information. Availability stresses that the security policy should ensure that all information processing is supported by functioning systems. It "establishes the hours of resource availability, system redundancy and recovery, and defines the periods of maintenance downtime" (Nussbaum, 2012). A security policy must have certain components. 

Components of a Security Policy

The following are components of a security policy based from RFC 2196, Site Security Handbook (IETF, 1997):

Access - which defines the rights and privileges. Essentially, this area of the policy provides guidelines for network connection and categorizes how data is addressed within a company.

Accountability - this defines the users, operations staff and management. This element of the policy should have an auditing mechanism built in that allows for intrusions to be detecting based on incident guidelines and stipulations.

Authentication - this creates trust by having users on the network to create effective passwords and overall setup remotely.

Privacy - continual monitoring must be performed of keystroke logins, user files access and electronic mail. 

Computer technology purchasing guidelines - these are requirements for the acquisition, configuration and auditing of computer systems and networks for compliance with the particular security policy. 

Security procedures must be developed. These procedures effectively and efficiently implement the security policy that a company executes. Security procedures are by and large communicated to both administrators and users in the element of class training. When creating a security policy, extensive discussion must be had on physical security, which "can protect a network from inadvertent misuses of network equipment by untrained employees and contractors. It can also protect the network from hackers, industry competitiveness, and terrorists walking in off the street and changing equipment configurations" (Oppenheimer, 2010). Hence, there need to be mechanisms in place within the security policy design that follow the guidelines of CIA.  Two key aspects of a security policy are auditing and authentication. As aforementioned, authentication refers to the capabilities of security equipment that permit certain processes to occur while a user is on the network. Auditing efficiently examines the network security from a procedural and incident based level. Data that is derived and analyzed should be based on accounting for both the pros and cons of the security policy.

Some systems have what is known as two factor authentication, which stresses that the user must have two types of identification (Oppenheimer, 2010). In addition to the mechanisms that will be implemented into a security policy for the company, there is also a need for discourse on the topic of encryption. Encryption is a type of process that seeks to keep data by scrambling it so that it can only be read by the person or persons that should be reading it. Data that is considered encrypted is known as ciphered data. Encryption is an extremely useful feature of confidentiality within a security policy. While authentication and auditing allow for a protection of data, encryption adds a supplementary protocol when certain arenas of the policy falter (Oppenheimer, 2010). Based on the prior deliverable, cloud technology is being utilized for the basis of the company, which in itself produces the need for even tighter and stricter security policy aspects.

While the traditional derivatives of a security policy can be put toward cloud technology, however, companies have to encounter what is considered "the biggest challenge of data encryption [which is] protecting the encryption keys" (Porticor, 2013). What is often recommended in a cloud technology security policy is to utilize "encryption algorithms such as AES-256 [as well as] specialized homomorphic encryption techniques to keep data safe when it is in the cloud. For organizations that [seek to] integrate data encryption into a type of automated environment, this adds and additional element of security to the existing cloud deployment" (Porticor, 2013). As technology continues to expand and change, the company will have to continually evaluate their security policy to ensure that it is meeting the current standards of the time.  

The following is a design diagram of the security infrastructure that the company will utilize. 

Section 2

(Design diagram for preview. Available via download)

References

DSLReports. (1999). What is a DMZ? Retrieved from http://www.dslreports.com/faq/4545

Nussbaum, C. (2012, May 3). Security policies. AtomRain. Retrieved from http://www.atomrain.com/it/enterprise-software/security-policies

Oppenheimer, P. (2010, October 4). Developing network security strategies. Cisco Press. Retrieved from http://www.ciscopress.com/articles/article.asp?p=1626588

Porticor. (2013). Porticor cloud security. Retrieved from http://www.porticor.com/

The Internet Engineering Task Force (IETF). (1997). RFC 2196, site security handbook. Retrieved from http://www.ietf.org/rfc/rfc2196.txt