13

We are a relatively small web development company with limited resources, but want to be able to stay on top of any announcements that may impact the security of our servers. After some searching, we have come to the conclusion that most sources of information (e.g. mailing lists, APIs built around CVE's) normally fall into two main categories:

  1. Too broad and noisy such that our small team can't keep up.
  2. Too specific, such that we would miss out on important information.

The one list we found which is an absolute must is the ubuntu-security-announce list, given that we run Ubuntu LTS versions on our servers. However the one thing that this is missing (from our perspective) is vulnerabilities in things other than software, such as protocols. The classic example is POODLE (CVE-2014-3566), for which the archives to not seem to contain anything relating to this at all (searching for CVE and browsing archives in Oct 2014). We'll continue to subscribe to ubuntu-security-announce though, because for important software bugs such as Heartbleed do appear.

Are people aware of web-security focused publications/mailing-lists which provide a curated list of recent vulnerabilities to supplement our subscription to ubuntu-security-announce?

Some good examples that we've found via other questions on this stackexchange site are:

  • us-cert bulletins (somewhat noisy, but well organised)
  • perfsonar vulnerability archives (extremely curated, and thus seems good at listing only the really big ticket items)
  • bugtraq mailing list (extremely noisy for a small software dev team)
  • cvedetails custom filters (difficult to know what to monitor for a general web-dev team)

Apologies if this seems a little broad, I'm happy to reword to make it suitable, as I believe there would be many other small dev teams looking for the same information and finding it difficult to know how best to keep on top of such a deluge of security information.

  • 1
    There are a number of commercial services that do this (Secunia, Symmantec, etc.) Do you need a free one? Ubuntu did respond to POODLE. One approach is to use Ubuntu packages for everything you can, and manually monitor anything else you're running. – paj28 Aug 11 '16 at 10:16
  • you could somewhat track a "noisy" list like bugtraq or full-disclosure and run a script that filter only the keywords of the technologies you're using / interested. – yzT Aug 12 '16 at 8:11
  • 3
    Possible duplicate of Software Library Vulnerability Tracking – drewbenn Aug 12 '16 at 17:55
  • I feel this is a valid question, where other industry members might share expertise about how they prioritise keeping themselves informed or how they (partly?) automate the task of identifying relevant CVEs. I would not recommend merging it with the similar question. – Steve Dodier-Lazaro Aug 16 '16 at 17:18
4

At scale, it's best to continuously vet your automation, but the most-important part: automation

For RHEL, CentOS, Fedora, et al there's yum-cron. You can even specify security-severity:Critical if you only want critical patches.

For Debian, Ubuntu, etc there's unattended-upgrades with similar concepts.

If you build applications or install custom apps, ensure you are covered there as well. Additionally, there's infrastructure to ensure patching. Automate it as much as possible. People will argue that this can break things. That's why I recommend you automate as much as possible -- but not so much that you break things. If you are only automatically installing critical security patches, then you are way less-likely to break things. Figure out how to automate it at least that much. Even if you have a policy to not directly automate without human approval -- automate gathering all of the information, download the patches, and have a push or pull mechanism, hair-trigger ready-to go.

OWASP has a lot of great integration capabilities via Dependency Check -- with even a web interface for it through this project -- https://www.owasp.org/index.php/OWASP_Dependency_Track_Project

One can integrate similar concepts to build servers and continuous-integration / continuous-deployment projects very easily. These environments are heavily-equipped for exactly this sort of automation. Many commercial solutions also exist -- it's easy to find them online.

1

I am aware of no such service that could be adapted for the communicated needs, though I am not sure the intelligence exists to create one that provides value without significant ongoing consumer-side attention.

I can think of 4 sets of information sources to pay attention to, listed below. Unless the specific circumstances of your business require attention to us-cert, bugtraq, or cvedetails, I would not include those in a list of useful sources.

The 4 sets are:

  • operating system
  • infrastructure provider
  • individual software providers
  • development platform/libraries

The general rule is- in the absence of an aggregated configurable source, the most important individual sources to pay attention to are the providers of the software and infrastructure being utilized, both in an operational context and in a development context. For those, follow both any specific security and releases announcements list as well as their general technical blog. Ubuntu's blog is where news about their response to POODLE was distributed (e.g. http://blog.canonical.com/2014/10/16/ubuntu-security-update-on-poodle-cve-2014-3566-and-sslv3-downgrade-attack/).

The OS is one layer in this sandwich. Below the OS, if the servers are virtualized in a cloud environment, then this rule comprises the cloud provider- AWS, Google, Digital Ocean, etc. AWS generally speaking has blogs for each major service- those will communicate information relevant from a security context.

If the virtualization or cloud platform also includes containers, then the blog, security, and releases announcements of the upstream container provider- Docker, linuxcontainers, etc- is worth following.

Above the OS are individual applications. These may be delivered by the OS provider but are nevertheless independent sources of news and information, because the curation filter of the OS provider is going to exclude important context related to features and configuration of these applications.

The importance of attending to these depends on their role in your infrastructure, and their role can be graded on two dimensions-

  • how visible they are to potentially malicious sources of traffic
  • how important they are in terms of securing your livelihood

You may have an important database that itself is not publicly exposed to potentially malicious traffic but it is nevertheless desirable to attend to their releases, security list, and technical blog as important architectural and defensive configuration information will get communicated there that will not come through other sources.

Similarly, you probably run nginx or apache web servers and some sort of application server. Ubuntu of course collects and processes information from the releases, security announcements and technical blogs of these projects, but again their curation filter will exclude specific issues of configuration and deployment that these projects will inform their users about directly.

As a web development shop, presumably your team works on one or more platforms- Node, Rails, Spring, React, whatever- consuming the platform releases of both the major providers and also of the library developers operating in that ecosystem and then producing software for your customers. Following the announcements and blog of both the platform and the library providers whose work you consume, and keeping up to date on dependencies, is important. Here there are some new services that focus on finding and curating vulnerabilities found through static analysis of development platforms and libraries, and then integrating that information into continuous integration/delivery workflows- these services are worth considering for your team.

The general rule again is- if you consume a service or an application as a dependency in your operational infrastructure, or if you consume an application or library in your development infrastructure, then following the announcements of those specific upstream providers is at this current state of maturity of the industry important for security.

The downstream providers who package and distribute software from upstream do not typically solve for configuration and deployment use cases that are security sensitive and that the upstream software providers spend a lot of time thinking about.

Finally, this is a lot of potential material to follow, which itself is an important point about attack surface. Because all software contains vulnerabilities, the more one consumes and utilizes the wider one's attack surface becomes. Consuming some software for its functionality and not attending to its upstream stream is an off-balance-sheet form of technical debt.

Hope that's helpful.

0

I have taken a somewhat different approach in the past.

Given that Linux distributors are actively monitoring upstream sources for new releases I used the package management system (in my case yast as I was running SuSe) from the command line to list any required updates.

I didn't trust this blindly; instead I sample checked a history of updates comparing the delay between the CVE being published and an update being published. The gap was in the region of 3 days on average. However I do acknowledge that a patch being released quickly is not guaranteed and that there is often other mitigations available other than waiting for a fix from the supplier (something several large software companies do not seem to acknowledge).

I am no export on apt, but I expect it should be possible to identify the required updates using aptitude.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.