Last updated at Mon, 28 Oct 2019 17:44:09 GMT

We primarily hear the term "secondary effects" after natural disasters: "an earthquake causes a gas line to rupture and a fire ensues" or "a volcano erupts and the sulfur cloud shuts down all flights across the Atlantic", but there are a lot of positive secondary effects out there. If developed properly, cloud applications bring with them secondary effects of singular events to benefit the customer community.

Since I work for a security company, I cannot write a blog post about cloud applications without addressing the obvious concern so many people have.

Cloud Security

The first question that every security professional needs to ask a vendor when considering a cloud application is "how have you secured your cloud?" because it is just proper due diligence. The first step that Rapid7 took when building a security product in Amazon Web Services (AWS) was to lay out the strategy to make it secure and scalable, so we did a great deal of research and recognized that if you go to the necessary lengths (as we did), a cloud application can be just as secure as an on-premise app. Despite this forethought, I still run into a great deal of security pros that would prefer to have the data reside on one of their servers so they can truly control it. This is a natural feeling that we have in the security industry because we have been taught to be paranoid and trust no one, but I liken it to why people feel safer driving a car than flying on a plane controlled by someone else, despite the fact that a pilot specializes and agonizes over flying the way that we do over securing your data. The next time you discover that a rogue server was set up in your organization without informing the security team, remember that security is the primary focus of our InsightIDR development team. Please always ask your vendors to walk you through the steps they have taken to secure your data in the cloud, so that you can take advantage of the secondary effects I will describe below.

Secondary Effect #1 - Quick reaction to change

One of the most common pains that I hear from incident response teams (internal or MSSP) is keeping the data flowing into their SIEM. The SIEM vendors are not to blame here; whether you are talking about firewalls, VPNs, or whatever other devices containing valuable information, the export formats vary widely and change without notice. The worst possible scenario here is that a concerning event occurs and the investigation warrants a look at firewall logs to quickly learn what happened, but those logs have not been reaching the SIEM since the last firewall software update (silently) changed the logging format.

Now, InsightIDR does not have the Nostradamus-like power to predict which vendor will change formats without notice, but it can take your team out of the silo that makes every team feel the same pain. Let me explain: once a single InsightIDR customer has set up, say, a Fortinet Fortigate firewall as an event source, the parser and collection method are there for all new customers to simply choose from a drop-down list and connect in seconds via syslog, a shared folder, or otherwise. This means that your team does not have to remember how they set up parsing of Fortinet logs at their last organizations or ever even see the logs in raw form. This helps in initial setup time, but it really helps when the firewall data suddenly stops reaching the InsightIDR cloud because the parsing rules have changed. One of Rapid7's customers will get a notification that data has stopped flowing, but the quick reaction of the InsightIDR team to update the parsing logic for this event source means that we will typically support the new format before other IR teams end up with a gap in data. The more organizations in the community, the lower the likelihood that your team even notices that log formats have changed.

Secondary Effect #2 - Detection that learns faster than any single person

Though it is not a pain as frequently voiced as changing log formats, I have heard a great deal of security leaders describe the challenge to find seasoned incident response experts. Typically, it comes in statements like "I worked at company X when they were breached and helped the team build detection for the techniques used there" or "I have a fantastic ArcSight guy and I don't know what I would do without him". Neither of these statements is a bad thing, but not every organization with security concerns can make those claims. In fact, I consistently hear that it is challenging for CSOs to fill the openings that are already approved.

This is where InsightIDR's customer base gets the benefit of what I call a collective mind. We generate a lot of our detection capabilities with our customers, whether it is simply a customer saying "I ran X with WCE and didn't get an alert" or Rapid7 creating a new alert and finding a few customers that want to test it out and make sure it brings value. If attackers used a certain trick to stay hidden in 2011, we will build a way to detect that, but more importantly, if they use a new technique in 2014 and a single person (Rapid7 employee, a customer, or even a friend) learns of it, the entire InsightIDR customer base will get the benefit of detecting that action in the future. Attackers are sharing techniques with one another, so our only possible way to keep up is to do the same in our detection.

Secondary Effect #3 - User behavior analytics across a larger dataset

There are a lot of "security analytics" companies emerging these days, so I feel it important to point out the biggest challenge you will have with the on-premise solutions: they only analyze the data in the silos I mentioned above. Reducing noise and correlating the right disparate data for detection across various sources grows slowly when there is no collective mind on which research and proactive analysis can be performed. It assumes that a security analytics solution already knows what data is important before install and it is not important to rapidly learn new use cases and adapt. This is why we believe it was necessary to build in the cloud, despite the natural resistance that some security teams still have.

If you want to take advantage of the secondary effects at your organization, please start the process and request a demo. We will happily step through the way by which we have secured our cloud.