Blog › Company

Johnathan Hodge

PCI – So what?

06.25.2014 | Posted by Johnathan Hodge

As we release the Sumo Logic App for PCI Compliance, I was reflecting on how tough PCI compliance is. It’s obviously an essential part of any organization’s IT strategy that handles credit cardholder information – but it’s tough – monitoring compliance across all the requirements is a big undertaking. And a mistake can have disastrous results.

Because of this, I really like the new guidance I read in v3 of the PCI DSS, released in November 2013, in the new section called “Implementing PCI DSS into Business-as-Usual Processes”. To do this, you need, amongst other things, excellence in monitoring, detection, timely root-cause analysis and well-designed remediation.

Now, the new PCI App from Sumo Logic obviously supports these things. With a broad array of dashboards, reports and searches specifically designed to monitor and detect potential issues across the 12 requirements, hidden within the terabytes of log files that many customers have, our PCI App is strong. But so what? Highlighting there is an issue is close to useless unless you provide the tools to take effective action in diagnosing root cause – making change happen. And as industry experts remind us, no matter what “us vendors” say, there are always false-positives that need to be examined and can get in the way of underlying issues. We’ve all used analysis tools that highlight an issue but then make it nearly impossible to take that critical step to true root cause identification. There’s little more frustrating than hitting that “So what?” moment.

What makes our PCI App exceptional and different is the fact it’s based on the Sumo Logic platform. Once we alert you to a potential failure, it’s simple to identify which Requirement to focus on, and from there to drill into the details. Our unique features, such as Anomaly Detection and LogReduce, make finding the needles in the remaining haystacks painless – and quick.

PCI App

 

 

 

 

 

 

 

 

 

So what? So, Sumo Logic’s PCI App will not simply highlight potential PCI infractions, it will dramatically reduce the time to root cause analysis – leaving you no time to even consider the “So what?” question. You will be too busy putting new measures in place to prevent the cause of the failure recurring.

Jana Lass

The Internet of Things…and by “Things” we mean Cats! [Infographic]

06.20.2014 | Posted by Jana Lass

The Internet of Things. The popularity of this topic seems to be growing just about as rapidly as as the amount of machine data generated by these “things” has.  A few weeks back, our beloved co-founder and CTO, Christian Beedgen, penned an article, The Internet of Things: More Connectivity Can Mean More Vulnerability, where he discusses some of the security challenges that exist around the exponentially growing number of devices connected to the internet.

Most major tech companies have written about or published infographics about IoT, yet when I read these articles or review infographics, they all seem to be missing a very obvious fact about the Internet…The Internet is made up of cats. To highlight what’s truly representative of our interconnectedness, we present you with an infographic around  ”The Internet of Cats.” Enjoy!

Cat-Infographic-Large

Amanda Saso, Sr. Tech Writer

Our Help? It’s in the Cloud.

06.16.2014 | Posted by Amanda Saso, Sr. Tech Writer

I like to fashion myself as a lower-level Cloud evangelist. I’m amazed at the opportunities the Cloud has afforded me both professionally and personally in the past four or five years. I tend to run head-first into any Cloud solution that promises to make my life better, and I’m constantly advocating Cloud adoption to my friends and family.

The consumer-level Cloud services that have developed over the past few years have changed how I relate to technology. Just like everyone else, I struggle with balancing work, mom duties, volunteer activities, and so on. Being able to keep my data handy simplifies my life–having records in the Cloud has saved me in several situations where I could just call up a document on my iPhone or iPad. No matter which Cloud app I’m using, I’m in the loop if I’m sitting at work or watching my kids at gymnastics (so long as I remember to charge my phone–there’s that darn single point of failure).

I respect Sumo for being a Cloud company that behaves like a Cloud company. We might have one physical server rattling around in an otherwise-empty server room, but I don’t know the name of it–I don’t ever need to access it. We run in the Cloud, we scale in the Cloud, we live in the Cloud. To me, that gives Sumo Logic an uncommon brand of Cloud legitimacy.

So what does all this have to do with Sumo Logic’s Help system? I started making noise about moving our online Help into the Cloud because I wanted the ability to dynamically update Help. At the time, my lovingly written files were somewhat brutally checked into the code, meaning that my schedule was tied to the engineering upgrade schedule. That worked for a while, but as we trend towards continuous delivery of our product, it wasn’t scaling. I knew there had to be a better way, so I looked to the Cloud.

My sense of urgency wasn’t shared by everyone, so I made a fool of myself at a Hack-a-Thon, attempting to make it happen. It was an epic failure, but a great learning experience for me. Knowing that I could spin up an instance of whatever kind of server my little heart desired was a game changer–what was once something that required capital expense (buying a Linux box or a Windows Server) was now available with a few clicks at minimal cost.

Within a month or so, I had convinced my manager of the legitimacy of my project. Eventually our Architect, Stefan Zier, took pity on me. He set up an S3 Bucket in AWS (Sumo runs in AWS, so this is a natural choice), then configured our test and production deployments to point to the URL I chose for our Help system. The last bit of engineering magic was leveraging an internal engineering tool that I use to update the URL for one or more deployments. Within a few days it worked. I now can push updates to Help from my own little S3 Bucket whenever I like. That is some awesome agility.

To those who are not tech writers, this may seem unremarkable, but I don’t know any other organizations with Cloud-based tech pubs delivery systems. I couldn’t find any ideas online when I was trying to do this myself. No blog posts, no tools. It was uncharted. This challenge really lit a fire under me–I couldn’t figure out why nobody seemed to be delivering Help from the Cloud.

The Cloud also improves the quality of my work, and grants me new options. Using an S3 Bucket means that I can potentially set up different Help systems for features that are only accessed by a subset of customers. I can take down anything that contains errors–which very, very rarely happens (yeah, right). I can take feedback from our Support team, Project Managers, Customer Success Team, Sales Engineers, and even from guys sitting around me who mumble about things that are missing when they try to write complicated queries. (Yes, our engineers learn about Sumo Logic operators using the very same Help system as our customers.)

Here’s the best part. As our team of tech writers grows (it’s doubled to two in 2014!), I don’t need an IT guy to configure anything; my solution scales gracefully. The authoring tool we use, Madcap Flare, outputs our Help in HTML 5, meaning that the writers don’t need any IT or admin support converting files, nor hosting them in a specific way. (Incidentally, when you check out our Help, everything you see was customized with the tools in Flare, using, of all things, a mobile help template.) Flare has earned a special place in my heart because my deliverables were ready for Cloud deployment; no changes in my process were needed.  There are no wasted resources on tasks that the writers are perfectly capable of performing, from generating output to posting new files. That’s the great part about the Cloud. I can do myself what it would take an IT guy to handle using any on-premise server solution.

Funny, that sounds just like Sumo Logic’s product: Instead of wasting time racking servers, people can do their job right out of the gate. That’s value added. That’s the Cloud.

Sanjay Sarathy, CMO

Differentiators

05.27.2014 | Posted by Sanjay Sarathy, CMO

As our growth has accelerated over the past few quarters, we’ve gained additional insights into what customers care about and why they choose us for machine data analytics.  In addition, our integrations and partnerships with Akamai, Amazon Web Services and ServiceNow have provided even more context around what customers investing in cloud services want and need.  I thought it would be instructive to share one perspective on what we’ve learned. 

  • Our cloud-native strategy is an asset, not just because of traditional TCO and elasticity reasons but because the fundamental cost of running a high-volume, cloud-based log management service that automatically detects patterns and anomalies is prohibitively expensive for customers choosing an on-premise alternative.  It goes back to a central point that many customers bring up with us – “we want to be users of the system, not administrators of it.”  
  • Our customers really care about Service Level Agreements.  Traditional SLAs focus on uptime/availability.  This is essential, but not always sufficient.  We’ve found that as a cloud provider in this space it’s also necessary to provide a SLA for query performance. Why? It’s quite simple. Query performance is essential to delivering on the promise of time-to-value, not just around initial setup, but also around ongoing operations.
  • My colleagues have previously discussed the rationale behind LogReduce and Anomaly Detection. One of the tenets of our product strategy is that the rate of growth of machine data has far outpaced the ability for human rules to automatically capture all insights in your logs. We thus need to combine machine learning with human knowledge to uncover both known and unknown events in machine data. This combination and the reason we invest so much in data science is the underpinning of our analytics strategy.  
  • Log data is “inherently” chatty and volumes spike when issues arise or seasonality goes beyond the norm. It’s during these periods that the need to instantly burst capacity to meet customer demand is critical. An on-premise environment cannot by definition get this done without having expensive spare capacity sitting around, a situation most organizations don’t typically provision for. It’s why we’ve incorporated elastic bursting to over 5x of your regular volume as part of our regular service.

These and other differentiators are a significant reason why we’ve grown by 500% over the past year.  We decided to take these differentiators and our other capabilities and make this part of our website.  Enjoy the read and understand where we’re focusing our R&D efforts to create a valuable machine data analytics service.  

Vance Loiselle, CEO

Sequoia Joins The Team and Eight Lessons of a First Time CEO

05.20.2014 | Posted by Vance Loiselle, CEO

I originally envisioned this blog as a way to discuss our recent $30 million funding, led by our latest investor, Sequoia Capital, with full participation from Greylock, Sutter Hill and Accel. I’ve been incredibly impressed with the whole Sequoia team and look forward to our partnership with Pat. Yet despite 300 enterprise customers (9 of the Global 500), lots of recent success against our large competitor, Splunk, and other interesting momentum metrics, I’d rather talk about the ride and lessons learned from my first two years as a CEO.

  1. It’s Lonely. Accept It and Move On.  My mentor, former boss and CEO of my previous company told me this, years ago. But at the time, it applied to him and not me (in hindsight I realize I did not offer much help). But, like being a first time parent, you really can’t fathom it until you face it yourself. I’m sure there’s some psychology about how certain people deal with it and others don’t. I’m constantly thinking about the implications of tactical and strategic decisions. I’ve learned that if you’re too comfortable, you’re not pushing hard enough. The best advice I can give is to find a Board member you can trust, and use him or her as a sounding board early and often.
  2. Trust Your Gut.  There have been many occasions when I have been given good advice on key decisions. One problem with good advice, is you can get too much of it, and it isn’t always aligned. The best leader I ever met, and another long-time mentor, would always ask, ‘what is your gut telling you?’ More often than not, your gut is right. The nice thing about following your instincts, the only person to blame if it goes awry is yourself.
  3. Act Like It’s Your Money. I grew up in Maine, where $100,000 can still buy a pretty nice house. When I first moved to California from Boston it took me some time to get accustomed to the labor costs and other expenses. The mentality in most of the top startups in Silicon Valley is “don’t worry, you can always raise OPM (other people’s money)”. Though I understand the need to invest ahead of the curve, especially in a SaaS-based business like ours, I also believe too much funding can cause a lack of discipline. People just expect they can hire or spend their way around a problem.
  4. Don’t Be Arrogant. Just saying it almost disqualifies you. Trust me, I have come across all kinds. Backed by arguably the four best Venture Capital firms in the business, I have had plenty of opportunities to meet other CEOs, founders and execs.  Some are incredible people and leaders. Some, however, act like they and their company are way too valuable and important to treat everyone with respect. Life is too short not to believe in karma.
  5. Listen Carefully. If a sales rep is having trouble closing deals, put yourself in his shoes and figure out what help he needs. If the engineering team is not meeting objectives fast enough, find out if they really understand the customer requirements. Often the smallest tweaks in communication or expectations can drastically change the results. Lastly, listen to your customer(s). It is very easy to write off a loss or a stalled relationship to some process breakdown, but customers buy from people they trust.  Customers trust people who listen.
  6. It’s a People Business. Software will eat the world, but humans still make the decisions. We’re building a culture that values openness and rapid decision-making while aligning our corporate mission with individual responsibilities. This balance is a constant work in process and I understand that getting this balance right is a key to successfully scaling the Sumo Logic business.
  7. Find the Right VCs at the Right Time. I can’t take any credit for getting Greylock or Sutter Hill to invest in our A and B rounds, respectively.  But I do have them to thank for hiring me and helping me. We partnered with Accel in November of 2012 and now Sequoia has led this recent investment. Do not underestimate the value of getting high quality VCs. Their access to customers, top talent, and strategic partners is invaluable.  Not to mention the guidance they give in Board meetings and at times of key decisions. The only advice I can give here is:  1) know your business cold, 2) execute your plan and 3) raise money when you have wind at your back.  Venture Capitalists make a living on picking the right markets with the right teams with the right momentum. Markets can swing (check Splunk’s stock price in last 3 months) and momentum can swing (watch the Bruins in the Stanley Cup – never mind they lost to the Canadiens).
  8. Believe. It may be cliché, but you have to believe in the mission. If you haven’t watched Twelve O’Clock High, watch it. It’s not politically correct, but it speaks volumes about how to lead and manage. You may choose the wrong strategy or tactics at times. But you’ll never know if you don’t have conviction about the goals.

OK, so I’m no Jack Welch or Steve Jobs, and many of these lessons are common sense. But no matter how much you think you know, there is way more that you don’t. Hopefully one person will be a little better informed or prepared by my own experience.

 

Jacek Migdal

Building Scala at Scale

05.12.2014 | Posted by Jacek Migdal

The Scala compiler can be brutally slow. The community has a love-hate relationship with it. Love means “Yes, scalac is slow”. Hate means, “Scala — 1★ Would Not Program Again”. It’s hard to go a week without reading another rant about the Scala compiler.

Moreover, one of the Typesafe co-founders left the company shouting, “The Scala compiler will never be fast” (17:53). Even Scala inventor Martin Odersky provides a list of fundamental reasons why compiling is slow.

At Sumo Logic, we happily build over 600K lines of Scala code[1] with Maven and find this setup productive. Based on the public perception of the Scala build process, this seems about as plausible as a UFO landing on the roof of our building. Here’s how we do it:

Many modules

At Sumo Logic, we have more than 120 modules. Each has its own source directory, unit tests, and dependencies. As a result, each of them is reasonably small and well defined. Usually, you just need to modify one or a few of them, which means that you can just build them and fetch binaries of dependencies[2].

Using this method is a huge win in build time and also makes the IDE and test suites run more quickly. Fewer elements are always easier to handle.

We keep all modules in single GitHub repository. Though we have experimented with a separate repository for each project, keeping track of version dependencies was too complicated.

Parallelism on module level

Although Moore’s law is still at work, single cores have not become much faster since 2004. The Scala compiler has some parallelism, but it’s nowhere close to saturating eight cores[3] in our use case.

Enabling parallel builds in Maven 3 helped a lot. At first, it caused a lot of non-deterministic failures, but it turns out that always forking the Java compiler fixed most of the problems[4]. That allows us to fully saturate all of the CPU cores during most of the build time. Even better, it allows us to overcome other bottlenecks (e.g., fetching dependencies).

Incremental builds with Zinc

Zinc brings features from sbt to other build systems, providing two major gains:

  • It keeps warmed compilers running, which avoids the startup JVM “warm-up tax”.
  • It allows incremental compilation. Usually we don’t compile from a clean state, we just make a simple change to get recompiled. This is a huge gain when doing Test Driven Development.

For a long time we were unable to use Zinc with parallel modules builds. As it turns out, we needed to tell Zinc to fork Java compilers. Luckily, an awesome Typesafe developer, Peter Vlugter, implemented that option and fixed our issue.

Time statistics

The following example shows the typical development workflow of building one module. For this benchmark, we picked the largest one by lines of code (53K LOC).

Example module build time

This next example shows building all modules (674K LOC), the most time consuming task.

 Total build time

Usually we can skip test compilation, bringing build time down to 12 minutes.[5]

Wrapper utility

Still, some engineers were not happy, because:

  • Often they build and test more often than needed.
  • Computers get slow if you saturate the CPU (e.g., video conference becomes sluggish).
  • Passing the correct arguments to Maven is hard.

Educating developers might have helped, but we picked the easier route. We created a simple bash wrapper that:
Runs every Maven process with lower CPU priority (nice -n 15); so the build process doesn’t slow the browser, IDE, or a video conference.

  • Makes sure that Zinc is running. If not, it starts it. 
  • Allows you to compile all the dependencies (downstream) easily for any module.
  • Allows you to compile all the things that depend on a module (upstream).
  • Makes it easy to select the kind of tests to run.

Though it is a simple wrapper, it improves usability a lot. For example, if you fixed a library bug for a module called “stream-pipeline” and would like to build and run unit tests for all modules that depend on it, just use this command:

bin/quick-assemble.sh -tu stream-pipeline

Tricks we learned along the way

  1. Print the longest chain of module dependency by build time.
    That helps identify the “unnecessary or poorly designed dependencies,” which can be removed. This makes the dependency graph much more shallow, which means more parallelism.
  2. Run a build in a loop until it fails.
    As simple as in bash:  while bin/quick-assemble.sh; do :; done.
    Then leave it overnight. This is very helpful for debugging non-deterministic bugs, which are common in a multithreading environment.
  3. Analyze the bottlenecks of build time.
    CPU? IO? Are all cores used? Network speed? The limiting factor can vary during different phases. iStat Menus proved to be really helpful.
  4. Read the Maven documentation.
    Many things in Maven are not intuitive. The “trial and error” approach can be very tedious for this build system. Reading the documentation carefully is a huge time saver.

Summary

Building at scale is usually hard. Scala makes it harder, because relatively slow compiler. You will hit the issues much earlier than in other languages. However, the problems are solvable through general development best practices, especially:

  • Modular code
  • Parallel execution by default
  • Invest time in tooling

Then it just rocks!

 

[1] ( find ./ -name ‘*.scala’ -print0 | xargs -0 cat ) | wc -l
[2] All modules are built and tested by Jenkins and the binaries are stored in Nexus.
[3] The author’s 15-inch Macbook Pro from late 2013 has eight cores.
[4] We have little Java code. Theoretically, Java 1.6 compiler is thread-safe, but it has some concurrency bugs. We decided not to dig into that as forking seems to be an easier solution.
[5] Benchmark methodology:

  • Hardware: MacBook Pro, 15-inch, Late 2013, 2.3 GHz Intel i7, 16 GB RAM.
  • All tests were run three times and median time was selected.
  • Non-incremental Maven goal: clean test-compile.
  • Incremental Maven goal: test-compile. A random change was introduced to trigger some recompilation.
Russell

Why You Should Never Catch Throwable In Scala

05.05.2014 | Posted by Russell

Scala is a subtle beast and you should heed its warnings. Most Scala and Java programmers have heard that catching Throwable, a superclass of all exceptions, is evil and patterns like the following should be avoided:

1 2 3 4 5 6 7
try {
aDangerousFunction()
} catch {
case ex: Throwable => println(ex)
// Or even worse
case ex => println(ex)
}

This pattern is absurdly dangerous. Here’s why:

The Problem

In Java, catching all throwables can do nasty things like preventing the JVM from properly responding to a StackOverflowError or an OutOfMemoryError. Certainly not ideal, but not catastrophic. In Scala, it is much more heinous. Scala uses exceptions to return from nested closures. Consider code like the following:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
def inlineMeAgain[T](f: => T): T = {
f
}
 
def inlineme(f: => Int): Int = {
try {
inlineMeAgain {
return f
}
} catch {
case ex: Throwable => 5
}
}
 
def doStuff {
val res = inlineme {
10
}
println("we got: " + res + ". should be 10")
}
doStuff
view raw scalaclosures.scala hosted with ❤ by GitHub

We use a return statement from within two nested closures. This seems like it may be a bit of an obscure edge case, but it’s certainly possible in practice. In order to handle this, the Scala compiler will throw a NonLocalReturnControl exception. Unfortunately, it is a Throwable, and you’ll catch it. Whoops. That code will print 5, not 10. Certainly not what was expected.

The Solution

While we can say “don’t catch Throwables” until we’re blue in the face, sometimes you really want to make sure that absolutely no exceptions get through. You could include the other exception types everywhere you want to catch Throwable, but that’s cumbersome and error prone. Fortunately, this is actually quite easy to handle, thanks to Scala’s focus on implementing much of the language without magic—the “catch” part of the try-catch is just some sugar over a partial function—we can define partial functions!

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
def safely[T](handler: PartialFunction[Throwable, T]): PartialFunction[Throwable, T] = {
case ex: ControlThrowable => throw ex
// case ex: OutOfMemoryError (Assorted other nasty exceptions you don't want to catch)
//If it's an exception they handle, pass it on
case ex: Throwable if handler.isDefinedAt(ex) => handler(ex)
// If they didn't handle it, rethrow. This line isn't necessary, just for clarity
case ex: Throwable => throw ex
}
 
// Usage:
/*
def doSomething: Unit = {
try {
somethingDangerous
} catch safely {
ex: Throwable => println("AHHH")
}
}
*/

This defines a function “safely”, which takes a partial function and yields another partial function. Now, by simply using catch safely { /* catch block */ } we’re free to catch Throwables (or anything else) safely and restrict the list of all the evil exception types to one place in the code. Glorious.

Sanjay Sarathy, CMO

Sumo Logic, ServiceNow and the Future of Event Management

04.29.2014 | Posted by Sanjay Sarathy, CMO

Today’s reality is that companies have to deal with disjointed systems when it comes to detecting, investigating and remediating issues in their infrastructure.  Compound that with the exponential growth of machine data and you have a recipe for frustrated IT and security teams who are tasked with uncovering insights from this data exhaust and then remediating issues as appropriate.  Customer dissatisfaction, at-risk SLAs and even revenue misses are invariable consequences of this fragmented approach.  

With our announcement today of a certified integration with ServiceNow, companies now have a closed loop system that makes it much easier for organizations to uncover known and unknown events in Sumo Logic and then immediately create alerts and incidents in ServiceNow.  The bi-directional integration supports the ability for companies to streamline the entire change management process, capture current and future knowledge, and lay the groundwork for integrated event management capabilities.  This integration takes advantage of all the Sumo Logic analytics capabilities, including LogReduce and Anomaly Detection, to identify what’s happening in your enterprise, even if you never had rules to detect issues in the first place.  

ServiceNow Integration

The cloud-to-cloud integration of ServiceNow and Sumo Logic also boosts productivity by eliminating the whole concept of downloading, installing and managing software.  Furthermore, IT organizations also have the ability to elastically scale their data analytics needs to meet the service management requirements of the modern enterprise.

Let us know if you’re interested in seeing our integration with ServiceNow.  And while you’re at it, feel free to register for Sumo Logic Free.  It’s a zero price way to understand how our machine data analytics service works.

PS – check out our new web page which provides highlights of recent capabilities and features that we’ve launched. 

Mitigating the Heartbleed Vulnerability

04.10.2014 | Posted by Stefan Zier, Lead Architect

skitched-20140410-094910By now, you have likely read about the security vulnerability known as the Heartbleed bug. It is a vulnerability in the widespread OpenSSL library. It allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to encrypt traffic on the Internet (including Sumo Logic).

How did we eliminate the threat?

When we were notified about the issue, we quickly discovered that our own customer-facing SSL implementation was vulnerable to the attack — thankfully, the advisory was accompanied by some scripts and tools to test for the vulnerability. Mitigation happened in four steps:

  1. Fix vulnerable servers. As a first step, we needed to make sure to close the information leak. In some cases, that meant working with third party vendors (most notably, Amazon Web Services, who runs our Elastic Load Balancers) to get all servers patched. This step was concluded once we confirmed that all of load balancers on the DNS rotation were no longer vulnerable.

  2. Replace SSL key pairs. Even though we had no reason to believe there was any actual attack against our SSL private keys, it was clear all of them had to be replaced as a precaution. Once we had them deployed out to all the servers and load balancers, we revoked all previous certificates with our CA, GeoTrust. All major browsers perform revocation checks against OCSP responders or CRLs.

  3. Notify customers. Shortly after we resolved the issues, we sent an advisory to all of our customers, recommending a password change. Again, this was a purely precautionary measure, as there is no evidence of any passwords leaking.

  4. Update Collectors. We have added a new feature to our Collectors that will automatically replace the Collector’s credentials. Once we complete testing, we will recommend all customers to upgrade to the new version. We also enabled support for certificate revocation checking, which wasn’t enabled previously.     

How has this affected our customers?

Thus far, we have not seen any signs of unusual activity, nor have we seen any customers lose data due to this bug. Unfortunately, we’ve had to inconvenience our customers with requests to change passwords and update Collectors, but given the gravity of the vulnerability, we felt the inconvenience was justified.

Internal impact

Our intranet is hosted on AWS and our users use OpenVPN to connect to it. The version of OpenVPN we had been running needed to be updated to a version that was released today. Other servers behind OpenVPN also needed updating.

Sumo Logic uses on the order of 60-70 SaaS services internally. Shortly after we resolved our customer facing issues, we performed an assessment of all those SaaS services. We used the scripts to test for the vulnerability combined with DNS lookups. If a service looked like it was hosted with a provider/service that was known to have been vulnerable (such as AWS ELB), we added it to our list. We are now working our way through the list and changing passwords on all affected applications, starting with the most critical ones. Unfortunately, manually changing passwords in all of the affected applications takes time and presents a burden on our internal IT users. We plan to have completed this process by the end of the week. 

Interesting Days

Overall, the past few days were pretty interesting on the internet. Many servers (as many as 66% of SSL servers on the net) are running OpenSSL, and most were affected. Big sites, including Yahoo Mail and many others were affected. The pace of exploitation and spread of the issue were both concerning. Thankfully, Codenomicon, the company that discovered this vulnerability, did an amazing job handling and disclosing it in a pragmatic and responsible fashion. This allowed everybody to fix the issue rapidly and minimize impact on their users.

Ariel Smoliar, Senior Product Manager

The New Sumo Logic Application Library

03.19.2014 | Posted by Ariel Smoliar, Senior Product Manager

Last July we launched our Applications webpage, and have been constantly adding new applications to this list. This week we are excited to announce a major step in delivering a better application user experience.  We have now integrated the Sumo Logic Application Library directly into core service and have made it available for both trial users and paying customers. 

The initial Library rollout includes the following applications: Active Directory, Apache, AWS CloudTrail, Cisco, IIS, Linux, Log Analysis QuickStart, Nginx, Palo Alto Networks, VMware and Windows. We updated the Sumo Logic user interface with a new “Apps” tab. You can install applications from the menu for a true self-service experience, without downloading any files. The dashboards for the applications you choose will be visible after following a few simple steps.

Apps library screenshot (1)

Over the coming weeks, we will add the remainder of the Sumo Logic Applications to the Library, including ones for Akamai Cloud Monitor, AWS Elastic Load Balancing, Snort, OSSEC, and more.  Till that time, we will manually load these applications for our customers.

What’s Next and Feedback

This is just the first phase in the rollout of our Application Library. We will continue to deliver more applications that provide critical insights into your operational and security use cases. In addition, we will continue to enhance the Library itself as a system to share relevant insights across your organization.

We are eager to hear your feedback on this initial phase. Please fill out this form if you would like to meet with us and share your experience using the Sumo Application Library.

 

Twitter