DevSecOps Stating The Obvious

I am not sure if it’s wise to use the term DevSecOps or not, but why not 😃

I will be sharing some of the very obvious practices to secure modern infrastructure, you know (AWS, CI servers, Kubernetes, Docker …etc)

all the new cool stuff 😃

Why I am stating the obvious? because people are forgetful, lazy, greedy and wishful in our industry

Let me start by one of my favorite quotes regarding threat modeling

“Threat modeling is really important, because if you’re not threat modeling and you’re making security decisions, you’re really throwing things at the wall and hoping for the best.” — IanColdwater

In my humble opinion that along with the typical planning and brainstorming about the threat modeling there are some tools the might help to light the dark

Monitoring, Logging, Alerting and Auditing (Trust, but verify)

Before defining a threat model or starting a certain type of practice you should monitor your systems, observe how the parties are behaving.

Log everything simply because you can’t tweak everything, for example, what if you have your server protected by all means, but someone gained unauthorized access. without logs you will be lost in the incident response, you have no idea what has been done, how did the attacker get it, did they plant another way to access or not.

Also through logging, you can check if the authorized parties are behaving as expected or not.

Of course, using monitoring and alerting is a passive practice, you want to be active, so you need to set up alerting, but what to alert on?

You can start by the obvious, and then start auditing, and asking why? is it needed? is there a better way to grant this access?…etc

Auditing helps you find the weak points of the system and not just auditing your logs, audit your setup as a whole, scan for misconfigured services, you know act a little red-teamy 😃

This is an ongoing practice, you should always be tweaking and updating your threat model based on the new findings.
You should always be tweaking your monitoring and alerting, assigning alerts to different teams, having severity levels for each event …etc

Two-factor authentication everywhere.

According to may recent reports the majority of recent attacks started with a password leak.

Your password was leaked somewhere on the internet, and you are using the same password for accessing your systems, and boom, everything is compromised especially if you are an admin.

Two-factor authentication should protect you from falling as a victim for such attacks.

Just google the name of the system + two-factor authentication

Let’s take it to the next level.

Use a single sign-on solution, this relieves the headache of revoking someone from all the systems, just remove them from one place, and they are no longer allowed to access any system.

Keep a book of people and their access (access matrix).

You should be maintaining a clear record of who can access what, this will help you remove them from systems after leaving the organization, or when you want to change their access level, or when you are auditing a certain incident.

Never store secrets in the code.

You have API keys, passwords, tokens whatever the secret is, you should never ever and under any circumstances leave them in the source code.

Use another solution to feed the secrets into your code at runtime, you can use similar solutions like:

Everything that doesn’t need to be on the Internet, should not

You have a self-managed CI server, a Kubernetes API, put it all behind a VPN, use a bastion, or whatever you come up with, but if it doesn’t need to be on the Internet, hide it from the public.

What if some parts of the Internet wants to talk to those systems, well the answer is obvious, whitelisting the IPs 😃.

My solution of choice is having a bastion server, of course, only ssh keys are allowed, no passwords and two-factor authentication on the server, this will guarantee that you need an authorized ssh key and for instance an authorized Google account.

Then people can tunnel through the bastion and get their work done, why I choose that because it’s simple and usually if your ISP is blocking/throttling traffic, most of the time the leave SSH alone.

No access to data stores, well not a hard no though

No person shall be able to directly access the data stores.

However, sometimes you need to change a record or get some data directly from the database, everything should be done through the code, write tools around the data stores for both reads and writes

For instance, if you need to do some analytics on your database, you shouldn’t allow the analytics tool to access the data store, instead create a dedicated read instance with only the needed fields readable, because if the analyzers have access on all the data whether they need it or not, it might get ugly.

i.e Reduce the exposure surface.

I know it’s ugly, but it happens, again here comes the benefit of logging monitoring and alerting.

When done, every keystroke should be recorded, imagine as if only the CTO is allowed to do such a change, and he sits you down on his laptop where he records every step you are doing.

And for the new cool kid in town (Kubernetes)

Well, as I said, people are lazy

Integrate security into every step

Use static and dynamic code analysis as part of your CI.

Have review systems blocking code with secrets in it.

Use vulnerability scanners against your app.

Teach your testers to do basic security checks.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store