Defensive Cybersecurity Strategies

→ Keep the ball away from the attacker.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I’ve wanted to write about this analogy for proactive versus reactive defensive security strategies for a while, and may add it to an upcoming cloud security presentation. The concept is a simple, but powerful mechanism to improve the state of your cloud security or cybersecurity in general. I wrote about it in a white paper called Balancing Security and Innovation With Event Driven Automation based on experiences and ideas that came from helping Capital One move production workloads to the cloud. I wanted to recap it in a fun way that is quick and easy to understand for those who don’t have the time to read a long nerdy white paper.

This blog post is sponsored by datree.io ~ a policy enforcement solution for confident and compliant code. As datree.io explains, “Software and application releases are accelerating, leaving less opportunity to review code for compliance with security policies. DevOps and security leaders know what organizational policies need to be in place to maintain the quality of releases, but the challenge is in enforcing those policies without slowing down development and without relying on individuals to remember to follow them.” The datree.io strategy aligns quite nicely with what I’m about to tell you. Why let a known security problem get into your environment at all if you can prevent it?

So here’s my story. I used to play basketball. Don’t ask me to shoot hoop now because I wouldn’t be able to hit the broad side of a barn (an American saying for — yeah, that ball is not going in the basket any time soon). I went to a small high school so, we were in a league where almost anyone who tried out got on the team. I knew how to play, make a hook shot, a jump shot, and so on and I played a bit at a small college but let’s just say I didn’t break any records — at least not the kind that one would want to disclose.

One of the things I had to contend with was girls who were taller and faster than me. I held my own in our small school league. I was not the best player, but I was pretty good on defense. I would typically be assigned to guard the tallest, fastest player on the other team. Somewhere along the way, maybe via a combination of my coach and my dad, I learned about denying the pass. The idea is to use strategies to prevent the player on the other team from getting the ball. If the player can’t get the ball, she can’t shoot! If she can’t shoot, she can’t score. Using this strategy, I was able to significantly reduce the number of opportunities a strong opponent had to attempt to score and usually they scored less than their average.

The alternative to this strategy would be to let the attacker get the ball and then try to stop them. The idea here is that you are defending the basket and you will prevent the player from scoring by standing between the player and the basket once they get the ball. In my experience, odds are better for a skilled offensive player to put the ball in the basket once they have the ball!

If the other player is faster than you, the latter strategy might end up looking like this — you’re trying to catch the attacker from behind after they get the ball and run past you.

…or this, where the attacker shoots over you…

Attackers score when they execute code on our systems to perform some malicious activity, such as stealing data. The attacker has to get code onto our systems to run it in our environment. The ability to do so typically results from some misconfiguration or human error. I like to think of getting onto virtual machines in the cloud or gaining access to leverage stolen credentials to change configurations as “getting the ball.”

Using the latter strategy from our basketball analogy, we use reactionary security tactics. We let developers and DevOps teams deploy whatever they want into production. We trust everyone to do the right thing but run monitoring tools and vulnerability scanners on systems in production. Then we react to a configuration that is non-compliant and roll it back automatically, or go tell a developer to fix a security flaw after deployment. What if the rollback fails? What if the attacker gets in before the correction occurs? What if the developer has other assigned priorities and no authority to fix the problem until it’s too late?

Wouldn’t it be better if we take away the opportunity for the offense to attempt a shot? Using tools like datree.io and others, we can implement strategies that monitor and validate system and software deployments — before they are deployed — by inspecting code and configurations and preventing those that are non-compliant or contain known security flaws.

An automated deployment pipeline with built-in security checks can stop a lot of the common causes of security problems from being deployed. You can also monitor what made it into production with a security flaw and who did it, in the case of exceptions — which there always are. We’ll still need to monitor systems running in production, but this moves the odds to prevent a breach a bit more in our favor.

If you think about it, most (not all) malware has to be installed or get into files on a system to execute. If you limit deployments to a secure pipeline and process and disallow deployments via other means, you effectively reduce the ability for malware to get installed in production. Attempts for malware to deploy itself in production would either fail or be easier to spot because it would be a non-compliant change that should trigger an alert.

Forcing all deployments through an automated deployment pipeline doesn’t mean you have to implement a draconian, slow process that rejects every flaw and false positive found by an automated scanning tool. If you build this pipeline correctly, it should make developers’ jobs easier by provide alerts to problems as they are being implemented and security training at the same time. I was a cloud architect, and later director helping a company move to the cloud. I told my DevOps team that if people are complaining about the pipeline — then either we aren’t doing it right, the developers need cloud security training to understand the reason for the security checks or both.

The deployment pipeline should be automated and make things easier for both security professions and development teams, not harder. Everyone needs to understand the reason for those checks. Building a combination of automated and manual security checks into deployments can be one of the best ways to reduce your attack surface and prevent compromised systems and data breaches. I’ll write about the second part of the paper — auto-remediation of security problems — in a future blog post.

Follow for updates.

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab

Summarize

Defensive Cybersecurity Strategies

→ Keep the ball away from the attacker.