Do any of these describe you?

You’re a Rails dev, you read the Rails Security Guide or some blog posts with some bits about security. You follow the advice given in those. You patch Rails and other gems when you hear about security vulnerabilities. Sometimes you try out some attack scenarios that you heard of and fix them in your app, too.

Either you’re not sure about the security measures in some parts of your app. Or you generally have a good understanding of web app security, but it’s just hard to keep up.

Maybe you’re a lead developer and your team generally keeps the app secure enough. Although, sometimes you feel there should be a system for how to keep up with security. A strategy before going into the details.

(Or maybe this whole security thing is new to you and you need some guidance where to start.)

If so, this guide is for you. The “Rails Security Strategy” guide is now available for free (by e-mail) or for just $6 (as a PDF guide). Click here to get the new guide

I want to help you creating a system to keep up with web app security even in busy times. It’s easy to get lost in details and feeling overwhelmed by the whole topic. An overall strategy is a high-level system that tells you exactly what to do if this or that happens and how often you should do this or that check.

The Rails security strategy

My article A week with a Rails security strategy introduced you to an approach for busy people. This new guide provides much more detail on how to develop and continuously review system-wide business rules concerning security, what other continuous efforts you’ll need and higher-level information for more security. And all that should fit into a busy schedule. So I introduced you to Mini Habits: Every weekday a little something.

Mini Habits

The key to mini habits is that you minimize your daily goal to an absolute minimum. Something too small to fail, that requires only willpower to complete, not necessarily motivation. The psychology behind it is that it’s much easier to use willpower, but we’ve only a limited amount of it. Motivation tries to push us out of our comfort zone, willpower just takes a few steps out and then back into our comfort zone. Have you ever done something automatically and noticed it only after a while? That’s a habit. It uses much less of our energy. Wouldn’t it be great to introduce top security into your application with just 10-30 minutes of work every day?

What is the overall approach?

Choose one or more of the following goals, minimize each and work on it every day or every week. All of the goals are detailed out in the guide. Some of them are clear action items, some are purely informational. So how to minimize a goal? For example, read 2 pages of the guide per day instead of a whole chapter. Or check only one gem for updates every day. It may sound silly, but I assume you’re busy and security isn’t your favorite topic. So you want to think about the days with ten meetings, a deadline, and 2 critical bugs: What can you still fit in when there’s no time at all?
And working continuously on a goal is important in order to turn it into a habit. Once it’s a habit, it will require fewer decisions and thinking – our brain will do some parts automatically. And plan already what to do next time it’s that goal’s turn, so you can start right away without losing time.

Frequency

Should you work on a particular goal every day or every week? It depends on the goal and on your priorities. Code quality is probably very important, so it can be a daily habit. Up-to-date software is important, but maybe you can only afford to check it once a week. After all, habits can also change over time. Bonus: Habits with activity-based triggers. For example, check the entire changeset in a different context again before committing (use gitk for a start).

Habit in teams

This is a little more tricky, but if you’re the team lead, you’re probably also responsible for security. So you should make sure the team works on security tasks continuously. If you know the code and software, you can work on forming a habit yourself first. Once you know exactly what happens during the habit, you can give the task to the team. However, the business rules that affect security (what I call a security policy) should be the decision of someone who has an overview of the entire application. So developing and reviewing the security policy is probably your goal.
It will be harder to keep everyone working on the security goals even on busy days, so maybe you’ve to adjust the habits every now and then. But imagine, how much easier it will be for the whole team if there’s a security strategy instead of uncertainty.

Here are my suggestions for the goals to choose from (more details in the guide).

Are you prepared for @terrible_event?

You’ll be glad to have tools, checklists and processes ready for these:

• Someone reports a security problem to you, or you discover it yourself. How and where will you tell your users about it?
• What’s the priority of security incidents? Can you reply to the reporter before she makes it public? Can you isolate the affected accounts and quickly block them?
• If passwords were affected, do you have any code prepared to require users to change their password or add additional authentication steps?
• What exactly will you say to your users in case of an incident?

Security response page

• Do you have a security response page for users to securely send you security-related bug reports and to update users in case of an incident?
• You’ll need rules for researchers on that security page, e.g. act in good faith and don’t use automated tools.
• If you have a budget for security, are bug bounties worth it?

Develop a security policy

A security policy is a set of high-level security business rules concerning, for example, secrets in the code, SSL/TLS or not, rules against XSS/CSRF, where to use encryption, minimum lengths, expiring tokens and what changes aren’t allowed because of security. Why do you need a security policy? To decide more easily whether a piece of code is in line with your general strategy. This will be handy when doing code reviews.
I’ll show you how to find existing rules and how to add new ones.

Prevention

This will be about how to do manual security reviews and checks on a regular basis. For example, using some time to reflect every week, or before every commit. And something like pull requests to review code in a team. Using different strategies, you’ll be able to find security-related code mistakes, but also make sure your code follows your own security policy from before. Also, your SSL/TLS security needs to be checked and adjusted regularly.

Incident discovery

Will you notice when someone is attacking or challenging your application? So this will be about logging, knowing how people are using the application, classifying requests and disallowing or throttling requests that you classify as malicious.

Quality Control, Automation and Deployment

Engineers like to automate, so we’ll talk about what to automate, and what not (yet). Automated tests and code checks increase consistency and make sure nothing falls through the cracks. However, do not solely rely on these. This will also be about what to test in terms of security and how much testing is too much.

Increased security in modern browsers

In the last few years, browsers implemented a lot of new security features that can be activated server-side via HTTP headers. Some are automatically activated in Rails now (but can be tweaked), and some aren’t. You should know what they are for.

Work environment and productivity

This module includes a few tips about git security and a more secure deployment strategy regarding server configuration and secrets. Also in this module: A productivity strategy when developing complicated features, for example in security-relevant areas.

Software updates

This might be obvious, but update your software and gems. This will be about how to keep your software up-to-date and what are secure software sources.

API security

It’s worth reviewing the API security and adding rules to your security policy regarding the API, too. This section will include an important check and will help you making informed decisions.

Get the Rails security strategy guide free