Forum Replies Created

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • in reply to: Network Access Services SLA #462

    We are certainly sensitive to not wanting to break existing solutions that are in production, and I assure you we take every measure we can to avoid that whenever possible.  That being said, we simply can’t state that existing solutions will not incur a charge to continue to support.  
    There are two major scenarios where I see this occurring.

    The first is when IT Security crafts new policies in response to emerging threats or best practices.   When this occurs we will respond with whatever measures IT Security dictates.  If this breaks an existing service, it will be up to IT Security to consider exceptions or recommend remediation measures on a case by case basis.  Such measures will likely incur a charge as it requires crafting a “one-off” solution that is outside of current security practices.  

    With respect to “grandfathering” when vulnerabilities exist in services, all vulnerabilities must be addressed within the time-frames described in the Vulnerability Management Program Component which is published at http://it.unm.edu/security/program/components 
    The other scenario is a result of the continuing evolution of technology.  Just as we’ve had to upgrade from FDDI and Token Ring to Ethernet, there will no doubt be future standards that require upgrades in order to maintain a standardized environment.  

    in reply to: Network Access Services SLA #402

    This is a new model that is being proposed so that we can better keep up with the costs of running the firewalls such as annual maintenance and hardware refresh.  This model has not been put into practice yet and customers will be notified prior to implementation if approved.

    in reply to: Network Access Services SLA #401

    We do not currently have any further information other than that the KSA review and SLA process may potentially lead to a different funding model for IT.  Any changes will be communicated as soon as they are known.

    in reply to: Network Access Services SLA #400

    I apologize, DNG is our groups abbreviation: “Data Network Group”.

    in reply to: Network Management SLA #396

    – Should the clause “Refrain from bypassing or circumventing security measures” use language from RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) that this is absolute?

    We will certainly ask our Agreements Committee to consider the wording.  Will leave this to the Agreements Committee to decide on preferred wording, and the wording was carefully agreed upon given the “educational” freedom at the University, and the delicate balance required for security and protecting the University.

    – Should the clause “Refrain from using any non-UNM IT supported network equipment (switch, routers, hubs, wireless access points);” use language from RFC 2119 (https://www.ietf.org/rfc/rfc2119.txt) that this is absolute?

    We will certainly ask our Agreements Committee to consider the wording.  Will leave this to the Agreements Committee to decide on preferred wording, and the wording was carefully agreed upon given the “educational” freedom at the University, and the delicate balance required for security and protecting the University.  Bear in mind there are still some departments on campus who have “network islands” separated by a firewall.

    – How is 99.9% uptime calculated and what goes into the uptime calculation? The 2 day time frame to repair broken equipment could possibly trigger an SLA violation of 99.9% uptime depending on how uptime is calculated. Is there an uptime calculation per department, zone, something else?

    Uptime calculations are performed by our networking monitoring software and is determined based on whether or not the monitoring tool can reach the device to poll it.

    The two day time frame is actually an incorrect carryover from a previous draft version and should say 1 day, we will correct it.  We do acknowledge that an extended repair window could cause a breach in the 99.9% SLA goal.  In all instances we strive to repair service outages as quickly as possible and in almost every case this is measured in hours and not days.

    We have dependency groups defined so that we can calculate uptime with granularity ranging from building, to zone, to entire campus.

    – How are degradations in service handled in the uptime calculation? Is there a certain threshold at which the network is deemed to be “down” due to a degradation in service?

    From an uptime calculation standpoint, if the device is up and reachable by the monitoring system then SLA calculation is not affected by degradation.  From a resolution standpoint, we recognize that a degradation can be just as impactful as a “down” device and prioritize and work the issue in the same manner.

    – “Include UNM IT in the planning and design phase of … new construction.” Should “Policy 5310: Information Technology for Facilities” be referenced here? https://policy.unm.edu/university-policies/5000/5310.html

    Great suggestion, thank you!

    – Should there be a separate section in the SLA for departments that have access to Tier 2 support?

    I am assuming that you are referring to departmental IT when you mention Tier 2 support.  In those cases this SLA is between departmental IT and central IT.  Several sections of the document make reference to departmental IT doing initial troubleshooting efforts prior to escalating to IT Networking.

    in reply to: Network Access Services SLA #394

    – beyond the annual report, is there a portal for customers to monitor network uptime and issues?

    ITAlerts is the location to monitor any ongoing issues, or upcoming planned outages.  At this time there is not a public portal for viewing our network monitoring application.  We certainly recognize that this would be useful to the campus community and will investigate whether access can be made available in a format that will be useful to our customers.

    – in the past, network performance has been affected by security issues – it’s understandable that UNM would not want to publish publicly on IT Alerts what the exact cause is. Would it be possible to publish, behind a NetID site, more detailed information for the UNM IT community? With an understanding of the situation, the UNM IT community could monitor and improve their security posture, and inform end users, generally, that the issues are due to an external threat.

    Major P1 incidents are reviewed internally, and then presented at IT UNM in order to give the campus community a better understanding of major incidents that have occurred.  Whether or not a site should be created for posting incident updates seems to be inclusive of all IT SLAs and beyond the scope of just network access.

    – would switches fall under the 2 business day failure replacement window? What happens if it’s a device affecting an entire building?

    The two business day text is a typo from a previous draft of this document, so we will update it.  UNM IT will be alerted within 5 minutes of a switch failure.  Every effort is made to keep sufficient spare parts on hand to respond to equipment failure immediately.  In the worst case, we would have to engage a vendor for next day replacement of hardware.  If this situation arises, we will always attempt to find a temporary solution to enable at least some functionality while we wait for equipment to arrive.

    3.1 and 5.1
    The KSA report references cost-recovery and so it appears that departments may now need to pay for things they didn’t previously (5.1), but may also need to pay for changes initiated by Networking/Security (3.1).
    It makes sense to clearly define in this SLA what services will incur charges, and what will remain core-services – if departments are paying for services, their expectations will be higher. Costs and related service expectations are then best noted here.
    To avoid misunderstandings, it would be useful to have a well-defined list:

    The KSA report does reference cost-recovery.  However, the Networks area has been a cost recovery model for quite some time, so this is no change to the business model.  We would like to point out that while you are not currently charged for “network access,” that is subject to change and we would certainly update the Service Catalog (which is the appropriate document for costs for the service).  We just wanted to re-iterate some of the common costs in the SLA, since most customers haven’t reviewed the Service Catalog.  The Service Catalog is referenced in paragraph 2 for your convenience.

    – of the customer initiated requests that will incur charges (firewall changes? DNS additions?)

    Minor requests to services such as firewall changes and DNS additions will not be subject to a charge, and are provided as part of the core service.  Note that there may be charges for department specific services.  For example, a standard firewall will be applied to all departments on campus.  If a department needs firewall service that is customized for their area, they will be charged a monthly charge for the dedicated firewall context.  Changes to that dedicated context would be covered under the monthly service fee.
    Other customer initiated requests that are larger in nature (i.e adding an additional switch or wireless capacity) will also have charges applied.  Again, the Service Catalog is the appropriate place to point out billable services, and we will always let the customer know prior to performing any work.

    – of all UNM Networking initiated changes that will be charged to customers (VLAN requirements? subnet redesigns?)

    UNM Networking initiated changes will not be charged to customers under normal circumstances.  Situations that arise from remediation of security risks or non-standard configurations may still incur a charge even if the change is initiated by UNM Networking.  An example of this would be if IT Security issues a policy to block a service at the campus edge.  If the department needs a solution designed that will allow them to continue using the blocked service while maintaining the security of the rest of the network, then a charge would be expected to be incurred.

    – Bullet 2 – deactivate hosts and departments
    – what is the notification process prior to deactivation?

    Most notification efforts will occur after the deactivation and not before.  This is due to the fact that deactivation is always  in response to an active threat and must be mitigated immediately.  In the case that a specific host(s) cannot be quickly identified, the smallest affected network segment that can be identified will be deactivated and departmental IT will be engaged to further isolate the compromised machine(s) prior to restoring network services.  In all cases, notification will occur as soon as possible and Central IT will remain engaged throughout the resolution process.  

    – in routine, non-emergency cases where UNM Networking or Security initiate a change that could affect departments, what sign-off or notification process would apply?

    ITAlerts will have all changes of this nature posted in advance.  If we are aware of a department that will be specifically affected by such a change, we will of course proactively reach out and try and give notification.  Due the variety of services on campus we will not always know who will be affected, therefore it will be important to monitor ITAlerts for changes that will affect your environment.

    – can a department be charged for work if there was no prior sign off or notification?

    If steps are taken by IT Networking to respond to an infection or misconfiguration of department resources, it is reasonable to assume that a charge will also be incurred even if no notification was given.  In the example mentioned above where an exception is needed to a new security policy or IT standard, charges will have to be discussed on a case by case basis.  If the charges are for a customer initiated Service Request, we will always communicate the costs and request a billing index and approval prior to completing the billable work.

    – what protocol is followed if a network change interrupts a department’s established business process (assuming the process itself did not represent a security issue)?

    The only non-security related ones I can think of would occur due to human error in IT Networking.  Unfortunately this does occasionally happen and we work with the department to resolve the issue as soon as we know about it.  When such incidents occur we will always notify the customer of the mistake that was made, and what steps we took to correct it while at the same time ensuring our documentation is up to date and team members are cross trained on the mistake that was made so it can be avoided in the future.

    – is there a cost to the department to remediate the change or create a workaround?

    No.  If IT Networking is implementing change, we are doing so to improve the network performance and/or security.  Charges would only result if a customer needs a complex configuration set up, and has coordinated the change ahead of time.

    – would items 6.1 and 6.2 then apply, where an Incident has occurred affecting the department, and would be assigned a Priority designation?

    In all cases a ticket should be opened.  If a service interruption has occurred this will be treated as a high priority ticket and addressed immediately.

    In all cases where a charge could occur, should a customer sign off and notification procedure be documented within this SLA?

    This SLA is not intended to address special case scenarios and simply points out that there are instances where charges may apply.  DNG service rates are posted in our service catalog for special case scenarios.  The Service Catalog is referenced with a link in Paragraph 2 for your convenience.

    • This reply was modified 8 years, 2 months ago by dstaylor.
Viewing 6 posts - 1 through 6 (of 6 total)