Oracle Network Management System Security Philosophy
A major mission of the NMS electrical model is to allow efficient capture and sharing of static and real-time field updates that allow for more informed and coordinated operational decisions. As such primary security measures typically involve minimizing the possibility of unauthorized (end-user) access or manipulation of the production Network Management System model. The most secure data cannot be accessed by anyone. A system that anyone can openly access and update may perform well but is certainly not secure. We have to find an acceptable balance of accessibility and security while providing a sufficiently performant system. The right balance generally depends on available infrastructure, cost as well as the needs and priorities of your organization.
At a high-level, a typical NMS installation can typically be thought of as two major components. A front-end user interface and back-end (black box) services to support the user interface. These two primary components are expected to be separated by an internal firewall for a production NMS deployment.
1. The NMS front end provides end-user clients access to the NMS electrical model. NMS supports Java (Swing) user client and limited user access with the browser based NMS Flex client.
• NMS end users are typically all within the corporate intranet behind a corporate firewall.
• Internet access (without VPN) is generally not allowed within an NMS production environment.
• The optional NMS Operations Mobile Application (OMA) can be an exception to this rule. OMA can be configured to support foreign crews and (if configured to do so) must (typically) allow some form of Internet access. OMA has its own security section later in this document.
• A large NMS instance may have over 1000 authorized users (sometimes over 500 at any given time). This user volume alone qualifies NMS end-users as a legitimate security threat. End user tools/access needs to be closely monitored/managed to help ensure NMS model integrity.
2. The NMS back end manages the operational NMS electrical network model.
• NMS back end technology components are expected to be deployed behind an additional internal firewall. The internal firewall is expected to be deployed in front of WebLogic - limiting NMS end user access to NMS back-end "services" via a single WebLogic port.
• Only internal authorized (admin) users should have access granted to the Oracle NMS back-end technology/service components (RDBMS, WebLogic, NMS services, GIS, CIS, and so on).
• Care must be taken to ensure that ONLY authorized administrative users have access to the Oracle NMS admin account.
The NMS high-level architecture and major product interfaces are shown in the illustration below:
Figure 1: Network Management System High Level Architecture
The following are generally relevant factors when considering what level of security/encryption is appropriate for core technology components within a given NMS deployment.
1. NMS generally does not typically contain extremely sensitive data.
2. NMS requires digital signatures to validate NMS Java clients connect to a trusted server.
3. NMS supports encryption of traffic between NMS clients (Java, Flex and OMA) and WebLogic.
4. NMS clients only have read access to a subset of (mostly) project configurable NMS RDBMS tables. Oracle NMS RDBMS read-only tables used for NMS end-user access should be screened for sensitive information before being configured for direct Oracle NMS client access.
5. NMS supports installing a firewall between NMS clients and the NMS back end (WebLogic).
The focus of NMS security revolves around properly authenticating and authorizing external integration adapters and NMS clients to minimize the possibility of unauthorized or inappropriate updates.
Data that travels between NMS end user clients and WebLogic can be restricted (via a firewall) to help prevent unauthorized access to NMS internal (back-end) technology components. Traffic between WebLogic and NMS clients is also typically encrypted (via t3s for WebLogic) to minimize the possibility of it being reverse engineered and/or tampered with and the NMS model being inappropriately updated.
Data that travels between NMS technology components on the back end is often not encrypted (because it is behind the corporate firewall AND often an additional internal firewall). There are also key exceptions to this encryption philosophy on the back-end. For example, communication of sensitive user authentication credentials to/from an LDAP accessible Directory Services is almost always via a secure protocol (LDAPS) - to help minimize the possibility of identity theft.
Together these measures are often adequate to reasonably secure a typical NMS installation - though additional measures can be taken if deemed appropriate. The remainder of this document provides a high-level overview of some of the available NMS security related configuration options.