DicksonOne + Security

Posted on: May 14th, 2014 by Matt M No Comments

Many environmental monitoring customers are quite concerned with security, especially when speaking on “the cloud.” Some might argue this is rightfully so, other would say that in many scenarios it’s less of a concern than its made out to be. However, that debate is for another time.

Today we’re discussing DicksonOne, Amazon Web Services (AWS), and security. I won’t be getting into the technicalities of DicksonOne and how we ensure it’s secure at the code level, but I will cover how we think about security and our customers data when designing and implementing DicksonOne. Below are 5 key areas we consider (and do) when making security related decisions.

1. DicksonOne utilizes Amazon Web Services (AWS)

Amazon Web Services are a suite of services related to hosting web applications. AWS is what’s referred to as Infrastructure as a Service. They provide us with servers for our applications, databases, storage, and other needs. It’s extremely scaleable and very secure.

AWS even meets the strict security requirements for the US Department of Defense. Amazon follows best practices with their offerings, and they outline their security and compliance quite well in the AWS Security Center and in their whitepaper dedicated to the topic (PDF).

2. DicksonOne is architected for security and redundancy

There are many parts to server and web application architecture, which all make up what a user would call “DicksonOne,” or the “website.”

DicksonOne utilizes the following building blocks to offer a redundant, secure, and scaleable product:

    • Load Balancers – This allows us to distribute traffic to our servers evenly across multiple app servers in order to prevent any given server from becoming overloaded and crash.
    • Application Servers – The part of the infrastructure that you, the user, interact with. It’s the user interface, the controls, and the layer that connects you to your data in the databases. We’re always running at least two application servers, so one server can pick up the traffic from another in the event one fails. We also add additional application servers as needed to keep the site running smoothly.
    • Databases – Where your data is stored. We’re always running at least two databases and the second is a 1 to 1 copy of the first, so we have an exact copy of the data in the event that the first fails. We also take regular snapshots of the system to have a restore point in the event of a major failure.
    • 3rd Party Services – We utilize a number of services to add functionality to our system. These include, but are not limited to Twilio (for texting and phone calls), Amazon SES (part of the AWS suite and used for sending emails), and New Relic (for tracking DicksonOne’s performance and errors). Utilizing 3rd party services is advantageous because it specializes certain sectors of DicksonOne. While they worry about one specific portion of DicksonOne, we can work to make the product as good as possible.
    • One way communication – DicksonOne loggers are designed so we cannot communicate to them directly. A logger must “ask” or make a request of the server and only then can the server indicate if any changes are necessary. This ensures the loggers cannot be controlled without first having initiated the request.

3. We code with best practices in mind

Our seasoned programmers have years of experience in architecting and coding web applications. All code is written, reviewed by a manager, then undergoes automated testing. Mentioned above, we use applications like New Relic to track performance and errors for DicksonOne. This allows us to a) be alerted to issues, b) target any issues in a timely manner, and c) establishes benchmarks so we know if we’re making improvements.

Additionally, we’re regularly upgrading the framework and code our system runs on to include the latest security patches and bug fixes. This, after all, is the beauty of the cloud: the ability to update the entire system remotely with minimal downtime.

4. Bank-level security

Some of our customers have exclaimed “you’re only storing temperature and humidity data!” in response to hearing we utilize the same encryption and security standards that the banks use for their online services.

Our response: we don’t see it as only temperature and humidity data (although we understand the sentiment). We take your data and the system seriously, and want to make sure it’s done right. DicksonOne has customers of all shapes and backgrounds: from Fortune 100 pharmaceutical manufactures to greenhouse hobbyists. We error on the side of more secure so that everyone benefits. Even you with the greenhouse!

5. We care about your privacy and your data

DicksonOne’s Terms of Service and Privacy Policy are written to protect both Dickson and the DicksonOne users. These documents create a set of standards that we must adhere to.

We do not share data from DicksonOne users. We store data well beyond the time an account is closed in the event a customer needs their old data. And, we want to ensure everything is secure and safe.

 

Ultimately, our goal is to provide DicksonOne as a secure and reliable service to make your environmental monitoring as easy as possible. If you have any specific questions feel free to email us.

Be Sociable, Share!
Tags: , ,

Leave a Reply