MENU
The GroundWork team has reviewed industry analysis of the recent Kaseya VSA incident, and while details are still being revealed, there are some useful take-aways we want to share. In particular, certain aspects of preparedness and indicators of active compromise can be monitored. We also want to talk a little bit about where GroundWork Monitor fits into security monitoring as a whole.
GroundWork Monitor Enterprise version 8.2.0 offers enhancements that build on the capabilities we have mentioned in past blogs. While all the dependencies, parent-child, and service and host dependencies are present as before, we have gone through our notification system and revamped it with an eye to making it easier to get the right alerts to the right people, with the right methods.
Read More
Major new version includes quick-start for automated Network Monitoring, supercharged Kafka-powered notification Engine, and APM features for comprehensive Unified Monitoring
SAN FRANCISCO, May 5, 2021 /PRNewswire/ — GroundWork Open Source, Inc., a leading provider of powerful IT infrastructure monitoring software, today announced the general availability of GroundWork Monitor Enterprise version 8.2.0, its flagship all-inclusive monitoring product. A major new version, the on-premises/in-cloud software package includes multiple containerized monitoring source applications, flexible automation for network monitoring, and innovative rapid-deployment notification integration options.
In our previous Blog, we introduced how we use Prometheus and the GroundWork Application Performance Monitoring (APM) connector to instrument a GoLang program to send metrics to GroundWork Monitor Enterprise. In this article, we continue with more Prometheus examples, but this time we demonstrate how to instrument a Java application with Spring Boot for easy monitoring. With just a few annotations, your Spring Boot application will generate metrics in the Prometheus Exposition format, and we will then show how easy it is to send those Spring Boot metrics to Groundwork Monitor.
We all want our monitoring systems to alert us when things go wrong. While it’s important to get alerts in the event of a failure or latency problem on something specific such as a SQL database, it’s actually just as important to not receive alerts from too many specific sources in the same alerting channel. If our monitoring system starts to fatigue us, we will ignore alerts until the phone calls and Emails from end users start letting us know a service is impaired or unavailable. Our monitoring solution should notify us both about specific failures in general and major issues, so we can differentiate and prioritize.
A single event, such as max processes in use on a database may not in itself be a problem that needs to be addressed on an emergency basis. A combination of events, though, such as a high value of max processes, a large amount of network discards, and slow response time for an http request can indicate a more general problem that is currently impacting the end users. We can easily monitor all of these conditions individually.
Part 2 of our Blog series on certificates focuses on a practical matter: using the free Let’s Encrypt certificates to secure servers that may not be publicly available, but still need better security than self-signed certs can give you.
As we explained in our last blog on this subject, to use HTTPS encryption with certificates, you can choose from a number of options:
GroundWork supports any of these (or even two at once on the same server). What you choose to use depends on a lot of things, like your tolerance for trust failure reports in your browser from self-signed or private CA certificates. Basically, only root-signed certs are trusted by browsers out-of-the-box, so unless you want to deal with users reporting and complaining about those failures, and explaining how to explicitly trust the certs you use, it’s best to use certs signed by a Root CA.
Lately, security has become top of mind across infrastructure monitoring customers. This is no surprise considering the widespread reports about supply-chain vulnerabilities and embedded compromises rampant in popular network monitoring software. In light of this, we want to underscore how seriously we have always taken our security processes, and how we cultivate a culture based on a foundation of sound security protocols.
We strive to be good stewards of our customer’s data and take great pains to ensure we are always on the bleeding edge of security best practices. A chain is only as strong as its weakest link, which is why we integrate secure processes into the development and deployment of GroundWork, and immediately respond to feedback and suggestions from customers. In this post we outline 7 ways in which our security policies manifest within the platform and our company culture.
In the last decade, it has become increasingly important to secure websites and applications using HTTPS instead of HTTP. A GroundWork Monitor installation is no exception, so in GroundWork 8, using HTTPS to access the system is the default setup, and you can add TLS certificates to it that you generate or purchase. See Adding Certificates to HTTPS for more information on doing so. TLS (Transport Layer Security) is the successor to the now-obsolete SSL (Secure Sockets Layer), and TLS certificates support the companion protocol that uses modern cryptography to ensure your HTTPS data on the wire cannot be usefully seen by or altered by third parties.
When dealing with certificates, there are many technical questions about how to efficiently and effectively manage the security setup on a web application. While GroundWork does offer several ways to manage certs and system naming, it’s important at the start to make sure you have the right certificates to begin with. To that end, this post describes a small tool we have developed to assist in this process. Future blog posts and documentation pages will cover additional aspects of the security setup on GroundWork systems.
Recent news reports of widespread infiltration of IT systems and the possibility of exfiltration of data are very concerning, and always brings up the questions:
In case you haven’t already seen a description, “Sunburst” is malicious code which attaches itself to legitimate libraries, installs itself as a service, then reaches out to command-and-control remote network infrastructure to prepare a second stage of attack: to move throughout the environment and compromise or exfiltrate data. Pretty nasty stuff, and we should all be concerned.
GroundWork Monitor makes it simple to monitor the health of Oracle databases, whether the need is simple monitoring of availability or for capacity planning purposes.
Oracle databases may be monitored either directly on the Oracle host or from a different host, using the GroundWork Distributed Monitoring Agent (GDMA). In both scenarios, SQL queries are used to provide the data from the database. This offers flexibility in that any Oracle query you create that returns a numerical result can be monitored as well as measured. As database monitoring needs vary on the organizational level – and even the database level, this flexibility is important.
