Network+

1.0 Networking Fundamentals

2.0 Network Implementations

3.0 Network Operations

4.0 Network Security

5.0 Network Troubleshooting

Practice Tests Overview

References You Need To Know

Explore

3.0 Network Operations

3.2 Explain the purpose of organizational documents and policies

Makiel [Muh-Keel]

Last edited 570 days ago by Makiel [Muh-Keel]

Plans and Procedures

Let’s take some time to examine the difference between policies and procedures.

Policies give people guidelines as to what they are expected to do. They're in place to direct things like how users access resources and which employees and groups get various types of network access and/or privileges.

Procedures are precise descriptions of the appropriate steps to follow in a given situation, such as what to do when an employee is terminated or what to do in the event of a natural disaster. They often dictate precisely how to execute policies as well.

For every policy on your network, there should be a credible related procedure that clearly dictates the steps to take in order to fulfill it.

What is Change Management?

Change should be introduced in a managed fashion. For this to occur, an organization must have a formal change management process in place. The purpose of this process is to ensure that all changes are approved by the proper personnel and are implemented in a safe and logical manner

You have to be careful when making any kind of change to an organization. Making even the smallest change to your systems can create a dramatic chain reaction to them. Example of IT corporate changes could be firewall configuration changes, modifying switch ports, Upgrading Software, etc. Change is often the most common risk in an enterprise.

Proper Change Management should have very clear documentation and policies on how changes should implemented in an organization.

Document Reason for a Change Clearly, every change should be made for a reason, and before the change is even discussed, that reason should be documented. During all stages of the approval process, this information should be clearly communicated and attached to the change under consideration.

Change Request A change should start its life as a change request. This request will move through various stages of the approval process and should include certain pieces of information that will guide those tasked with approving or denying it.

Configuration Procedures The exact steps required to implement the change and the exact devices involved should be clearly detailed. Complete documentation should be produced and submitted with a formal report to the change management board.

Rollback Process Changes always carry a risk. Before any changes are implemented, plans for reversing changes and recovering from any adverse effects from them should be identified. Those making the changes should be completely briefed in these rollback procedures, and they should exhibit a clear understanding of them prior to implementing the changes.

Potential Impact While unexpected adverse effects of a change can't always be anticipated, a good-faith effort should be made to identity all possible systems that could be impacted by the change. One of the benefits of performing this exercise is that it can identify systems that may need to be more closely monitored for their reaction to the change as the change is being implemented.

Notification When all systems and departments that may be impacted by the change are identified, system owners and department heads should be notified of all changes that could potentially affect them. One of the associated benefits of this is that it creates additional monitors for problems during the change process.

Approval Process Requests for changes should be fully vetted by a cross section of users, IT personnel, management, and security experts. In many cases, it's wise to form a change control board to complete the following tasks:

Assure that changes made are approved, tested, documented, and implemented correctly. Meet periodically to discuss change status accounting reports. Maintain responsibility for assuring that changes made do not jeopardize the soundness of the verification system.

Maintenance Window A maintenance window is an amount of time a system will be down or unavailable during the implementation of changes. Before this window of time is specified, all affected systems should be examined to identify how essential they are in supporting mission-critical operations. It may be that the time required to make the change may exceed the allowable downtime a system can suffer during normal business hours, and the change may need to be implemented during a weekend or in the evening.

Authorized Downtime Once the time required to make the change has been compared to the maximum allowable downtime a system can suffer and the optimum time for the change is identified, the authorized downtime can be specified. This amounts to a final decision on when the change will be made.

Notification of Change When the change has been successfully completed and a sufficient amount of time has elapsed for issues to manifest themselves, all stakeholders should be notified that the change is complete. At that time, the stakeholders (those possibly affected by the change) can continue to monitor the situation for any residual problems.

Documentation The job isn't complete until the paperwork is complete. In this case, the following should be updated to reflect the changed state of the network:

Network configurations Additions to network Physical location changes

Why have an Incident Response Plan?

Often, when an attack or security breach occurs in the network, valuable time and information are lost in the critical first minutes and hours after the incident occurs. In some cases, evidence is inadvertently destroyed, making prosecution of the offending party impossible. In other cases, attacks that could have been interrupted and prevented before damage occurs are allowed to continue.

An incident response plan or policy is designed to prevent this by establishing in advance the procedures that should be followed when an attack occurs. It may categorize incidents in such a way that certain event types (such as an active port scan) may require a response (such as disabling certain services) within 10 minutes while other events (such as an attempt to access a file without proper credentials) may only require a notation and follow-up in the next few days. The point is to establish these rules ahead of time to ensure that events are handled in a way that minimizes damage and preserves evidence.

Disaster Recovery Plan A disaster is an emergency that goes beyond the normal response of resources. The causes of disasters are categorized into three main areas according to origin:

Technological disasters (device failures)

Manmade disasters (arson, terrorism, sabotage)

Natural disasters (hurricanes, floods, earthquakes)

The severity of financial and reputational damage to an organization is largely determined by the amount of time it takes the organization to recover from the disaster. A properly designed disaster recovery plan (DRP) minimizes the effect of a disaster. The DRP is implemented when the emergency occurs and includes the steps to restore systems so the organization can resume normal operations. The goal of a DRP is to minimize or prevent property damage and prevent loss of life.

Business Continuity Plan One of the parts of a DRP is a plan to keep the business operational while the organization recovers from the disaster; this is known as a business continuity plan (BCP). Continuity planning deals with identifying the impact of any disaster and ensuring that a viable recovery plan for each function and system is implemented. By prioritizing each process and its supporting technologies, the company can ensure that mission-critical systems are recovered first and systems that are considered luxuries can be recovered as time allows.

One document that should be created to drive this prioritization is the business impact analysis (BIA). In this document, the impact each system has on the ability of the organization to stay operational is determined. The results list the critical and necessary business functions, their resource dependencies, and their level of criticality to the overall organization.

Standard Operating Procedures Once your business is launched, each department leader will need to develop practical methods to implement their assigned tasks using the specific part of the business model's blueprint that relates to their branch. These practical methods, or protocols, must be compiled into a standard operating procedures manual and followed closely. The procedures in your manual will have been included for different reasons and have varying degrees of importance and implementation. If you form a partnership or acquire another company, it will be crucial for its business protocols to either match or be compatible with yours.

Hardening and Security Policies

One of the ongoing goals of operations security is to ensure that all systems have been hardened to the extent that is possible and still provide functionality. The hardening can be accomplished on both a physical and logical basis. From a logical perspective:

Remove unnecessary applications.

Disable unnecessary services.

Block unrequired ports.

Tightly control the connecting of external storage devices and media if it's allowed at all.

But hardening is only a part of the picture. There needs to be a set of security policies that are enforced through the use of security profiles, sometimes also called baselines. Let's look at some of the more important policies that should be implemented.

Acceptable Use Policy Acceptable use policies should be as comprehensive as possible and should outline every action that is allowed in addition to those that are not allowed. They should also specify the devices and websites that are allowed and the proper use of company equipment.

Bring Your Own Device (BYOD) Policy The security team must have a way to prevent these personal devices from introducing malware and other security issues to the network. Bring your own device (BYOD) initiatives can be successful if implemented correctly. The key is to implement control over personal devices that leave the safety of your network and return later after potentially being exposed to environments that are out of your control.

Security Policy So what, exactly, is a security policy? Ideally, it should precisely define how security is to be implemented within an organization and include physical security, document security, and network security. Plus, you have to make sure these forms of security are implemented completely and solidly because if they aren't, your security policy will be a lot like a block of Swiss cheese—some areas are covered, but others are full of holes.

Data Loss Prevention The data loss prevention policy defines all procedures for preventing the egress of sensitive data from the network and may include references to the use of data loss prevention (DLP) software.

Data leakage occurs when sensitive data is disclosed to unauthorized personnel either intentionally or inadvertently. Data loss prevention (DLP) software attempts to prevent data leakage. It does this by maintaining awareness of actions that can and cannot be taken with respect to a document.

For example, it might allow printing of a document but only at the company office. It might also disallow sending the document through email. DLP software uses ingress and egress filters to identify sensitive data that is leaving the organization and can prevent such leakage.

How is sensitive data transferred?

What is Common Documentation?

Building a great network requires some really solid planning before you buy even one device for it. And planning includes thoroughly analyzing your design for potential flaws and optimizing configurations everywhere you can to maximize the network's future throughput and performance.

Start planning by creating an outline that precisely delimits all goals and business requirements for the network, and refer back to it often to ensure that you don't deliver a network that falls short of your client's present needs or fails to offer the scalability to grow with those needs

Physical Network Diagram A physical network diagram contains all the physical devices and connectivity paths on your network and should accurately picture how your network physically fits together in glorious detail. Again, I know it seems like overkill, but ideally, your network diagram should list and map everything you would need to completely rebuild your network from scratch if you had to

⁠

Never forget to mirror any changes you make to your actual network in the network's diagram. Think of it like an updated snapshot.

Logical Network Diagram Physical diagrams depict how data physically flows from one area of your network to the next, but a logical network diagram includes things like protocols, configurations, addressing schemes, access lists, firewalls, types of applications, and so on—all things that apply logically to your network. Figure 14.6 shows what a logical network diagram could look like.

And just as you mirror any physical changes you make to the network (like adding devices or even just a cable) on your physical diagram, you map logical changes (like creating a new subnet, VLAN, or security zone) on your logical network diagram. It is important that you keep this oh-so-important document up-to-date.

⁠

Floor Plan It's always helpful to have a floor diagram. One of the uses of this is when performing a WLAN site survey. When it's input to the survey software, you can indicate the types of materials found in all walls, doors, and so on, and the survey software can determine the best location for APs.

It can serve as a plotting bed if you have a wireless IPS that has at least three sensors. In that case, when the system sees a rogue AP or evil twin, the software can triangulate the location of the rogue AP and plot it on the floor plan, making it simple to physically locate it and remove it.

⁠

Wiring Diagram Wireless is definitely the wave of the future, but for now even the most extensive wireless networks have a wired backbone they rely on to connect them to the rest of humanity. That skeleton is made up of cabled physical media like coax, fiber, and twisted pair. Surprisingly, it is the latter—specifically, unshielded twisted-pair (UTP)—that screams to be pictured in a diagram.

Picture of a Rack Diagram Below

⁠

Main Distribution Frame (MDF)

Exactly what it sounds like, the MDF is the center point of the entire network. Its commonly seen as apart of the existing data center. This is identical to the ‘Core’ part of three-tier architecture. A Main Distribution Frame (MDF) is the primary hub or demarcation point that interconnects private or public IT and telecommunication lines coming into a building to an internal network via any number of intermediate distribution frames (IDFs).

Example: Cables that enter a central office or customer facility must first connect to a centralized MDF closet, then to each individual IDF closet, and finally onto to workstations. For instance, a business located across multiple floors of a building may have an MDF on the first floor that connects to public lines from outside the building. That MDF then connects those lines to the internal network via an IDF placed on each individual floor.

MDF stands for Main Distribution Frame and IDF stands for Independent Distribution Frame. An MDF is the main computer room for servers, hubs, routers, DSL's, etc. to reside. An IDF is a remote room or closet connected to the MDF, in which you can expect to find hubs, switches, and patch panels.

Intermediate Distribution Frame (IDF) acts as extensions of the actual MDF. This is an extension of the MDF. You can think of it as an auxiliary of the MDF, and it is a place where you’re able to bring your users and connect them into the main network. There are going to be uplinks from here to the MDF.

This is where you usually have switches for a floor or workgroup. There’ll be local resources or anything else that doesn’t need to be in the center of the network. You will commonly see IDFs in medium- to large-scale environments where you have users on different floors or in different buildings, and they’re usually separated by geography.

Audit and Assessment Report When audits and assessments are performed, there should be reports created that organize the collected information in a format that can be understood by those who are charged with making security decisions based on the reports. The language should be clear and all terms used should be defined. Keep in mind that decision makers do not always have the same security skills as those they manage.

Common Agreements

In the course of supporting mergers and acquisitions, and in providing support to departments within the organization, it's always important to keep the details of agreements in writing to reduce the risk of misunderstandings.

Nondisclosure Agreement (NDA) A nondisclosure agreement (NDA) is an agreement between two parties that defines what information is considered confidential and cannot be shared outside the two parties. An organization may implement NDAs with personnel regarding the intellectual property of the organization

Service-Level Agreement (SLA) This is an agreement that defines the allowable time in which a party must respond to issues on behalf of the other party. Most service contracts are accompanied by an SLA, which often include security priorities, responsibilities, guarantees, and warranties.

Memorandum of Understanding (MOU) This is an agreement between two or more organizations that details a common line of action. It is often used in cases where parties do not have a legal commitment or in situations where the parties cannot create a legally enforceable agreement. In some cases, it is referred to as a letter of intent.

Plans and Procedures

What is Change Management?

Why have an Incident Response Plan?

Hardening and Security Policies

What is Common Documentation?

Common Agreements

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.