Encryption has gone mainstream. Thanks to the numerous data breaches (781 during 2015 in the U.S. alone) data security is a top priority for businesses of all sizes. Semi-vague language like “we ensure our data is protected” from IT teams is no longer good enough to satisfy the concerns of business executives and their customers. CEOs are losing their jobs and companies are suffering financial losses/fines that reach into the millions of dollars when poorly encrypted or un-encrypted data is lost.
The real benefits and value of Drop Guard are not about being able to monitor, but actually perform updates by committing the newer Drupal and modules versions directly into the project's Git repository. In this article, we'll familiarise ourselves with the basic Drop Guard concepts, and go through the update behaviours configuration process to secure our website.
Hi, it’s me, Johanna! I’m responsible for the Marketing around Drop Guard, our update automation tool for bad ass Drupal security (yes, this is a promotion) - and I’m a Drupal greenhorn.
On Friday, April 8th, I had my first meeting with the Drupal community at the Drupal Business & Community Days in Heidelberg. This merging of community part and business presentations was the first one ever organized that way, apropos by Erdfish, thank you so much for your dedication! So my entrance in the Drupal World started a little bit uncommon.
Today, we’re excited to introduce you to a number of new features, improvements and fixes for Drop Guard - the first update in the series of releases planned for 2016. It includes many enhancements designed to improve user experience when creating projects in Drop Guard, support for the "Unsupported updates", and even smarter automated patching workflow. Read below to learn about the major improvements and don't forget to check your Drop Guard account to check it by yourself. Let's dive right in!
Drupalgeddon vulnerability, also known as SA-CORE-2014-005 affected millions of websites back in 2014 and we believe it started a new era for the Drupal community. It became apparent that if you don't want to put your website or business to a huge risk it's not enough to check for its status once a month, or even once a day - you should be continuously and tirelessly be scanning all available sources of information for potential security vulnerabilities in your code, being prepared to take immediate action.
With this post, we are starting a new series - "Drop Guard recipes". It will be all about things which help us to be more productive, efficient, provide better service to our customers and ensure better security for Drupal. As you might expect, it will be mostly Drop Guard related, but we promise there will be a lot of interesting stuff for everyone. Stay tuned!
First of all, let's agree that if you or your team uses some sort of modern development workflow - which essentially means the path the code makes from the point it was originally written to the production website, you should be familiar with feature branches concept. Apart from traditional "dev", "stage" and "master" branches, you create separate named branches for website features or code updates which are not yet ready to be merged upstream.
We, at Drop Guard, are extremely concerned about all things Drupal security. Security is not something that can be taken for granted after ordering a security review, or passing through a "security checklist", or even after switching to Drop Guard for updates handling. We should always remember that security is a continuous process, and it consists of numerous bits and pieces requiring your attention all the time.
Luckily enough, Drupal is a highly modular system, and instead of reinventing the wheel we can take advantage of the existing and battle tested solutions which are aimed at helping us with ensuring the continuous security for our applications.
We've collected the essential security-related modules in our view, and split them into two categories - passive (designed to monitor and provide information) and proactive (designed to take action or make changes to application configuration to ensure stronger security).
6 January 2016 was a memorable day for the Drupal community. Probably for the first time since the Drupalgeddon a vulnerability with potential to affect millions of websites was discovered. The report on the insecure Drupal update process, published by IOActive, got immediate traction and responses from Acquia, Drupal Security Team and major players in the community.
Sven Culley is a professional Drupal expert in Germany. He provides Drupal development and maintenance services for his clients. Sven takes a huge responsibility for every site as he needs to care about security, updates and hassle-free operation. Sven will tell us in this short interview, how he organized his work between development and maintenance tasks and how he wins the trust of his clients.
Spot on Sven Culley
Sven, we want to know how you run your Drupal business and provide maintenance services to your clients. Your answers will be used to present your reliable drupal shop in our Drop Guard Blog and to show others how you care about your client's site security.
When and why did you join the Drupal community?
We are working tirelessly to make Drop Guard better, faster and more friendly for developer. In this blog post we present you a "sneak peek" of our revamped project creation process, with this end in mind to please you with greater usability for getting started with your project in Drop Guard!
So let's get more detailed: the creation process will be split into 3 independent configuration screens.
Before this first modification, our users had to go through all the steps of the project creation wizard at once. Oh my, that was awful. Now the process is much simpler by allowing to save the project just after entering it's title, connecting to the Git repository and setting up a few very basic settings.