If You Fail to Plan

Contact Jason White

If Only I Knew How

A developer friend of mine (and his wife especially) wondered how I landed this magical job where I could work remote with occasional travel (I think they’d like to live somewhere where tech jobs aren’t necessarily plentiful). They asked me about what I did, as application security had interested him some. He wondered about the knowledge and skills needed to work in this sort of job. I quizzed him a little on basics like SQLi and XSS and gave him some tips. As we continued to talk about AppSec, he admitted… “I would focus more on secure coding if I knew what that really meant”.

His attitude/experience is not really rare. Having worked in the development trenches, I can tell you that any focus on security outside of compliance is rare.You can read more of my thoughtsabout that if you’d like.Today I’d like to offer something of more substance than a rant or motivational speech for those that would like to focus on secure coding, but don’t know where to get started.

Security Doesn’t Happen by Accident

In myprevious post, I suggested that developers should be included in ‘blue teams’. Traditionally, they are not; however, their products will likely be sitting on your front and/or back lines during blue-vs-red exercises. You know, those same products that are sitting on your network every day.

Any developer knows that projects or phases within a project often have kick-off meetings and/or periods of design and documentation early on. During these, application development and/or deployment plans are laid out, reviewed and discussed. Security should be included in that planning.

The … Well, a List

In the interest of brevity on this post, I’m going to lay out a list of topics/questions and provide some links (pretty much all to OWASP documentation) as a starting point. Each application will need specific consideration. This list covers a lot of common topics across web applications. Doing mobile development? Trust me, there’s plenty of overlap in here, especially since your mobile app probably connects to some web server/service in the end anyway.

So, what should you be planning & documenting early on? First, let’s talk about the broad strokes:

You should be considering what your threats/risks really are. You should do some Threat Risk Modeling . What are the threats and risks your application faces? This should help you align your efforts appropriately and avoid unproductive trips down rabbit holes. You should also be planning how you are going to test your security controls. The OWASP ASVS is a good, active project to help with that.

Now that you have an idea of what your threats might be and how you plan to test your controls for them, let’s consider your actual security controls. As noted, this will not be accurate or exhaustive for all applications (since each application will require individual consideration). Let’s take on some common ones that are still prevalent.

How will you query your data source? SQL (hint: parameterized queries) or NoSQL, you to want to avoid injection by a malicious user, right? What is your anti-CSRF solution? Many platforms (e.g. Apache Tomcat, Spring) come with them on-board now. Pick your solution, deploy it and test it once implemented. What is your Anti-XSS solution… Training developers (hint: output encoding, not black-listing)? Can/ will you use a centralized filter, wrapper or similar solution? This may get overlap with other items, but what security headers will you set automatically in your app? What about information you don’t want leaked via headers? What are your authorization rules/policies ? And… how will you audit/enforce them? Keep in mind, you have to consider vertical as well as horizontal access control. We’ll talk a
little more about this one in a moment as it’s a favorite of mine. How will you log security events? What, if any action will be taken in case of a given type of security event. BTW, there’s a cheat sheet and a project that might be handy for the logging of security events. Of course, you’ll need to determine what constitutes different types of security events. I’ll give you a good starter case… what if a request comes in and it has clearly bypassed your client-side validation (and your server-side validation matches the client, right)?

We security people always talk about ‘ defense in depth ’. So, your planning may also include things like:

Where does your database (or other assets in your architecture) sit in relation to your application (there is some separation, right?), and how will you securely connect to it? Will you use a WAF or RASP to add another layer of protection ? Will your application include end-to-end encryption? Access Control Example

To quote an older OWASP Wiki page :

“Without documenting the security policy, there is no definition of what it means to be secure for that site.”

While it’s one of the more dated pages on the OWASP Wiki, it is entirely accurate today . It’s also something I have very rarely seen done. So, here’s a brief example of what such a policy/matrix should (or could) look like.

This example assumes/uses a fictional RESTful application, so Methods (HTTP Methods) map as follows generally …

GET view POST create PUT update DELETE delete

Alternatively, documenting via Class#method might look like this:

With that documented, you can test against it.

As the Saying Goes

We’ve all heard it at some point in our lives … “If you fail to plan, you plan to fail”. That goes for the security posture of your application too.