Do you know how many websites are running in your organisation?

You might be surprised to see the number, not only of actual web servers – but also the number of sites those web servers are serving.

Open-AudIT has a built-in query to easily show you the websites (even those not running) in your organisation.

Information is presented in an easily readable table format that is exportable to CSV (Excel), HTML, XML and JSON formats.

For each website you will see – the name, OS and environment of the computer running it, the web server name and the sites name, description, status, instance log status, log format, log rotation policy and directory.

To enable the query go to menu -> Admin -> Queries -> Activate Query. You will see a list of available queries. Click the ‘tick’ icon on the right side to activate the “Web Sites” query and make it appear in your menu’s.

NOTE – Open-AudIT currently retrieves the most information from IIS based servers, but Apache servers on Linux are also catered for. Watch this space!

Your AntiVirus console should tell you which PCs have their AntiVirus software installed. But will it tell you which PCs don’t have their AntiVirus software installed? What about your server’s that live in a DMZ or another disconnected network? What about AntiVirus software from another vendor?

Because Open-AudIT captures the programs installed on a PC, Open-AudIT can report on specific installed programs very easily.

Open-AudIT contains a query for installed antivirus software which will tell you not only which PCs have which AntiVirus software installed, but also those without AntiVirus software installed.

Information is presented in an easily readable table format that is exportable to CSV (Excel), HTML, XML and JSON formats.

This is a very simple query and can easily be extended by the user to add additional software names when checking (if your antivirus software name doesn’t match the default names provided).

To enable the query go to menu -> Admin -> Queries -> Activate Query. You will see a list of available queries. Click the ‘tick’ icon on the right side to activate the “Installed AntiVirus” query and make it appear in your menu’s.

Now go back to the homepage and click on the name of a group.

Once you see that group of devices, click menu -> Queries -> Installed – AntiVirus.

Done. How easy was that!

Over the last decade or so, I have worked with many organisations and while all of them are different, they have many things in common. One thing organisations have in common is the need for more flexibility in the authentication system to give them the ability to provide access to resources being managed by the people who need to see them, this needs to include the ability to view individual resources, like interfaces and chart data, which are defined at a lower level than the operating system (e.g. a node). It needs to be possible to permit users of the network management system access to more specific data from almost arbitrary objects.

Over the last few months, Opmantek has been working on an alternate authorization system which will permit our customers to be able to define views of what is being managed so that they can permit their customers to see information that they might not ordinarily be able to see without giving them access to view an entire node.

A simple example of the benefits of this capability would be for service providers who have shared equipment, where multiple customers are using one or more interfaces from one or more switches. This might be a metropolitan area network, with switches in the basements of buildings and each customer uses one or more interfaces.

With our new multi-tenancy authorization, roles are created for each customer and the associated user names, then several business service views are created by selecting the interfaces of one or more switches and adding them to a business services view for the customer. When the customer logs in, they have access to see the business services view and all of the associated interfaces. They are then able to drill into the interface to see the statistics.

Another good example of this might be an IT Services company which provides general IT services to businesses, along with network and server management. Amongst the equipment being managed are some telephones and the related network interfaces. A partner of the IT services company assists with the management of the phone systems and requires the ability to see switch ports which the phones connect to. With traditional authorization schemes the telephony engineers would require logins giving them permission to see the entire switch including interfaces for things not related to their duties.

With the new multi-tenancy authorization, a business services view can be created and the required telephony interfaces added to that view. When the telephony engineer logs into the system, they will only see the interface information they need to keep an eye on the telephony system.

As an option, the ability to display summary node information in business services views is also available, allowing key operational summary information to be shared without providing access to the full device. When clicking on an interface name, it is possible to see the detailed graph of the interface.

While providing this is already very powerful, we felt that providing more detailed access would also be beneficial, so we have extended this capability to the charts and maps in opCharts. This means that you can create a chart including, for example, the CPU load of several devices, and then permit the customer to view that chart. The same applies to maps.
Going forward Opmantek will expand this capability significantly to include more granularity in the authorization and more resources available to be permitted. We will also work to simplify administration of the system wherever possible.

We are very excited by being able to take authorization to a new level of flexibility and simplicity, enabling our customers to in turn be more flexible with their customers and manage third party vendor access more diligently.

I have the pleasure of working with dozens of engineers every month from companies all over North America. No matter the type of business they work for I have found they all have one thing in common – they’re all trying to maintain larger and more complex networks with a smaller team of staff.

Network management systems strive to automate the user experience, from the implementation of complex scheduling systems to the use of heuristics engines to assist with event handling. The one piece that is often missing is the maintenance of the monitoring solution itself. Recently Opmantek had the opportunity to address this issue head-on. What we did, how it works, and the results we achieved are the subject of this article.

Like many North American businesses, our client, a large multinational corporation, had grown over the years through several mergers and acquisitions. Their infrastructure management consisted of several disparate platforms from more than a dozen vendors.

Our implementation services include a series of up-front workshops designed to elicit information and feedback from all levels; engineer to upper management. When we conducted these investigative meetings we discovered many challenges and pain points specifically to our client’s business. We also learned that they had Service Now – a configuration management database (CMDB) – that was being used as the company’s single source of truth for all equipment inventory. This gave us an idea…

Service Now, like most modern CMDB systems, includes a very robust application programming interface (API). Using this API we were easily able to create an integration which would pull a list of active devices, compare them to the devices currently being monitored, and reconcile the list by adding new devices, updating existing devices, and even retiring devices from monitoring when they were marked as out of service.

Our architectural solution for this client included a series of geographically diverse polling engines all rolling-up to a series of redundant primary servers. Each layer offering multiple methods of redundancy and failover. Our integration with Service Now accounted for this, automating the assignment of devices to polling engines geographically, even supporting devices with different service levels; some need 1 or 2 assigned polling engines.

To further enhance the system, we also automated the assignment of devices to opConfig, our Configuration and Compliance Management solution and opEvents, our intelligent event management system which provides event correlation, deduplication, and action automation. These solutions were then complemented by the addition of opTrend, which expands on Opmantek’s already expansive thresholding and alerting system by implementing a highly flexible Statistical Exception Detection System (SEDS), Igor Trubin’s methodology, that learns what’s normal behavior on the client’s network and adjusts thresholding dynamically based on historical usage for every hour of each day of the week.

Our Phase 1 implementation focused on network devices and have allowed the client to consolidate their monitoring platform to a single Opmantek based solution, decommissioning several other systems. In our next Phase, we will be automating the monitoring of their expansive server network. This effort will continue to leverage the information in Service Now; allowing us to monitor services and applications, generate synthetic transactions to exercise each application tier, and continue to expand their view across the enterprise through a single pane of glass.
The last piece of this puzzle was the addition of Service Assurance and Monitoring. This provides an additional layer of support through monthly server checks, software upgrades, and 24/7 monitoring of the monitoring solution. With these solutions in place the client needn’t worry that they will miss an event because their monitoring solution wasn’t up-to-date or worse, wasn’t functioning as designed.

In all, Opmantek’s integrated solution has now removed the maintenance needed to maintain most network monitoring systems, ensured all devices are properly monitored to the correct SLA and delivered an enterprise-class solution through a single pane of glass.

Managing a large complex environment with ever changing operational states is challenging. Several of our engineers who previously managed shifts in large 24hr Network Operation Centres described how they used Automated Live Base Lining when starting a shift and during shift handovers to immediately understand a network’s current health and recent history. NMIS Live Base Lining was able to provide them with a fast synopsis of current network stability and an ability to quickly drill into the most relevant occurrences.

Live base lining is achieved by automatically calculating a single “network wide” health metric, reachability metric and availability metric as seen in this graph.

The secret to showing engineers where to look for deteriorating conditions is that the current state (metrics) of your network are then continuously compared against a rolling period (configurable, last 8 hours by default) to see whether performance is deteriorating or improving. This is done not only on the network as whole but also on subsections (groups) of your network.

Status trends are reported visually using arrows to show if health is improving or declining. You can then drill-down into more detailed KPI data for an individual device.

The visual alerts, along with the ability to very quickly access detailed information relating to performance deterioration allow an organization to identify issues and make corrective decisions faster – vastly improving mean time to resolution (MTTR).

Our new major feature for 1.10 is the beginning of our Baselines feature. This is not finished as yet (in 1.10), but we wanted it out there for feedback. Baselines in Open-AudIT Enterprise allow you to take the details of one machine (say it’s software list) and use that as a basis for comparison against another machine or group of machines.

Being able to determine which machines are configured the same is a major part of systems administration and auditing – and now reporting on that will be made simple and automated. Once you define your baseline it will automatically run against a set of devices on a predetermined schedule. The output of these executed baselines will be available for web viewing, importing into a third party system or even as a printed report.

For example – you might create a baseline from a device running Centos 6 which acts as one of your apache servers in a cluster. You know this particular server is configured just the way you want it but you’re unsure if other servers in the cluster are configured exactly the same. Baselines enables you to determine this.

So you can say “Take the software installed on device X and tell me where it’s different on all the machines in the Web Servers group.”

You get a nice GUI interface showing which machines did or did not meet the expected software install state. You can also apply this to users and netstat ports. Other tables will be introduced in the future.

Our initial release (in 1.10) is functional but not yet complete. You can create a baseline, run it against a group of devices and view the results in a web browser. We plan to add scheduled execution, more tables for comparison (currently only software, netstat ports and users are enabled), in place baseline and policy editing, archiving of results, exporting of results and more.

A sample baseline definition screen is below. In this example we show a baseline consisting of software policies targeted at Centos 6 devices.

Once this has been run against our target group we have a result which is below.

From our result page we can inspect individual devices or individual policies for compliance.
Once we have completed the implementation of Baselines in Open-AudIT you will see how powerful this feature can be for reporting items like compliance, ensuring device consistency and more. Stay tuned for more Baselines in our next Open-AudIT release!

Terms:

Baseline – the overarching document that contains the baseline definition and the individual policy tests.

Policies – The individual tests contained within a Baseline. Each test is for a specific item. An example would be testing for SSH version 1.2.3.