Security Doesn’t Have to be Hard

Security.

Even just hearing the word can make any IT engineer wince.  In most big enterprise environments, when you think “security” you think about that compliance engineer who every month brings you a list of vulnerabilities they found that you need to fix by next month.  Inevitably, some portion of them break capabilities, and you’re left wondering what these fixes even fix.

Unfortunately, if you read the news at all, you’ll see that security isn’t something we can just ignore, either.  Its like social media; lots of people proudly proclaim they don’t use it, but if you have any sort of consumer-facing product or service, then if you’re not using social media you’re not doing it right.

So, as I tend to do, I wanted to understand the strategic view and build a top-down approach.  Now, I’m not a CISSP, a CASP, a GISP, or anything like that (well, I’m a CSSLP*) but I decided to do my own research into the why’s of security, instead of just the how’s.  And what I found was interesting. This is something where Pareto’s Rule applies.

80% of your vulnerabilities on your attack surface can be mitigated by 20% of your actions.

That huge list of vulnerabilities?  Yeah, forget about it (for the moment).  If you want to truly implement defense-in-depth, there’s only a couple of things you need to be doing to cover the basics.

1. Patching.  Every day if you can.
2. Actually use logging.  And actually monitor it.
3. Use common sense.  By that I mean, don’t run clear-text passwords or leave your admin passwords to the default, stuff like that.

That’s really all it takes.  Let’s look at these.

Patching

If you’re not doing this at all, it’s fairly easy to just turn on automated patching (or cron jobs) and that will cover the basics.  In a critical customer-facing system, however, I’m not a fan of automated patching because I have seen patches break applications and cause downtime.  What you really need to do here is set up a duplicate of your production environment, ala Staging, and have automated patching turned on there.  Then you can smoke test that system before you patch in Production.

(And before you say this sounds hard, if you’re running at all virtualized than this isn’t hard.  Because you’ve got your install and build process automated, right?)

Logging

In a large, comprehensive enterprise, where you’ve got a dedicated security team, then this is as easy as having them actually look at your logging dashboards and alerts every day, whether this be your ELK, Splunk, SolarWinds, or Whatever system.  If you don’t have a dedicated security team, then either set the automated alerting up for your Ops personnel, or just outsource it. Log monitoring is actually one of the more worthwhile SaaS capabilities available today.

If you don’t know what you should be looking for in your logs, neither did we.  So here’s where I started:

https://www.owasp.org/index.php/Top_10-2017_A10-Insufficient_Logging%26Monitoring

https://www.sans.edu/cyber-research/security-laboratory/article/sixtoplogcategories

Reading these two areas, we came up with a list of “Top 20” things and that’s what we implemented first.  Over time we gradually added more and more things.

Common Sense

As for common sense, yes there’s a lot of room for jokes here.  But it’s still surprising to me how many times I see basic security principles bypassed, just because of time constraints.  I’m not talking about complicated configurations, I’m just talking about, hey, did you change the password for your root database user from “password” to something more challenging?  This is where discipline needs to come into play. Basic security issues like this need to be treated just like any other bug, and prioritized.

Does all this sound like too much work?  Well, there are a couple of other strategies that you can use to make this easier, and perhaps even transfer all this work and risk to someone else.

• Automation, or DevSecOps
• SaaS Security Products
• PaaS Hosting
• Serverless Infrastructures

I’ll talk more about these in upcoming blog posts, but basically there are ways to accomplish the security basics without needing a full time person working on it.

Now look, you need to (as I said above) use some common sense.  If you’re facebook.com or bankofamerica.com, obviously you need to have a comprehensive security program in place (although I suspect you already do).  And remember, of course, that all these things above do are mitigate your network-based attack vectors. This doesn’t protect against some of the most common vulnerabilities, such as insider threat or social hacking.  But if you’re struggling to understand what you need to be doing, implementing the above is a first step in ensuring that you have your systems and data protected.

 

* Updated July 2020: Actually, now I’m a CISSP, a CSSLP, and AWS Security Specialty Certified!