Gartner Blog Network


Security Essentials? Basics? Fundamentals? Bare Minimum?

by Anton Chuvakin  |  June 20, 2014  |  15 Comments

Let’s think together – what technologies and practices constitute information security essentials? The question is actually bitchingly hard – so think before answering! One way to think of this is to imagine somebody describing his security capabilities to you, and when they miss something from that list you go “ZOMG!!! No way you missed X! What are you, stupid or something?! STOP talking to me and go deploy/do/buy that now!!!”

First, it is probably NOT just “firewalls and SSL” (and anti-virus) – endpoint security and data security should be represented, as well as possibly cloud security. Also, some practices will span both information security and IT operations, such as asset management, change management, patch management, etc. For example, PCI DSS is not a bad list of basics, as some would say.

So, let me try my hand at this admittedly thankless task (we may do a formal research project on this latter…)

This first batch are the “unquestionables” (IMHO):

  • Security policy
  • Firewalls/network segmentation
  • Transit data encryption
  • Authentication
  • Anti-malware
  • Vulnerability management (including remediation such as patch management)
  • Incident response

This batch is strong contenders:

  • Security awareness
  • [Some] risk assessment
  • Stored data encryption
  • Log analysis and monitoring

And this batch starts to cover what can be called debatable:

  • NIPS
  • WAF
  • Lots of other stuff that I am too lazy to mention – this last section can be long!

(as you noticed, the list mixes tools and practices, but favors tools slightly; this is not intentional)

And, of course THE primary risk is that the list is BOTH “too long” and “too short” – at the same time (a complaint frequently tossed in the direction of PCI DSS)

Here are some attempts to ponder this question or come up with specific lists of “cyber security” things to DO and BUY:

BTW, Ben, I am not stealing your thunder – I just wanted to start this discussion :-)

Loosely related blog posts:

Category: philosophy  security  

Anton Chuvakin
Research VP and Distinguished Analyst
5+ years with Gartner
17 years IT industry

Anton Chuvakin is a Research VP and Distinguished Analyst at Gartner's GTP Security and Risk Management group. Before Mr. Chuvakin joined Gartner, his job responsibilities included security product management, evangelist… Read Full Bio


Thoughts on Security Essentials? Basics? Fundamentals? Bare Minimum?


  1. […] Source: Security Essentials? Basics? Fundamentals? Bare Minimum? […]

  2. Osama Salah says:

    The problem with this kind of articles is that they can be misinterpreted by some as a formula for implementation or prioritising. Information security, while I don’t contend that there are some basic principles, is more complex than that (or else we would have solved that messy problem a long time ago). For example a WAF is listed as “debatable” while for some it could be quite essential (for example a shop compensating for lousy coding practices). Also the maturity of the implementation varies according to need. Some situations need a simple firewall setup, others need a more complex one; thus checking of “Firewall” from the list isn’t going to be very beneficial. Context is important.

    One technology I see frequently ignored is Application White listing. Besides firewall that’s probably the only other technology that actually implements the default deny principle.

    Best regards
    Osama Salah

  3. Pete Hewitt says:

    I’m going to hop on my soapbox here and say that over, above and ahead of everything else, the first rule should be: stop end users from running as Administrator / root. The second: administrators should only run as Administrator / root to do administrative tasks. By far, that gives you the most bang for the buck.

  4. @osama

    >The problem with this kind of articles is that they can be
    >misinterpreted by some as a formula for implementation
    >prioritising.

    Well, not really as “the basics” was meant to be a list of ONLY items of “priority 0”

    @pete

    >stop end users from running as Administrator / root.

    Agreed — at the end user PC, non-admin access only does wonders for security!

  5. Comments received from information discussions:

    ADD TO THE BASIC LIST:
    Authentication (including password and account management, but not full IdM)
    Some DAST (some app sec testing) for internet apps
    Security awareness
    Cloud provider contract management

    ADD TO STRONG CONTENDERS LIST:
    Mobile device encryption – phone and laptop
    Logging for servers and devices, such as privileged user logging, change logging
    Non-admin user rights on laptop/desktops

  6. More comments from informal discussions:

    Move risk assessment to BASICS

    Even before basics what is needed is a good inventory and a classification of critical assets / information to protect.

  7. Ron Parker says:

    These are great points but don’t we already have some lists in the environment?

    The SANS Critical 20 is a good example of a list that is based on other standards. It tries to put some priority or criticality on the steps.

    Would it be better to begin again or to attempt to improve an existing list that has some vetting and investment already?

  8. Anthony Fiorito says:

    No doubt that security awareness is an essential. Bad guys go after our individual users all the time.

    I would leave risk assessment in the second bucket. If you don’t do the basics well, risk assessment is wasted effort.

    I think you need to get web content filtering in there somewhere. I’m think in the strong contenders list.

  9. Doug says:

    What level of protection does “essential” or “basic” represent, against what threat? I believe an answer to that question is necessary before listing controls and practices. Additionally, are controls and practices alone determinant of resistance to threat?

  10. Pete Herzog says:

    One thing we found in our research is that Authentication is the LAST operational control you should implement. As with no other controls in place, anyone can just bypass Auth with bruteforce, phishing, and so many more ways. Same with anti-malware. No solution out there will stop enough to matter. Get your other controls like file integrity and subjugation in place and then throw your money away on anti-malware bc then at least you can really contain and isolate when the anti-malware fails. We saw that any security you add directly to the desktop is just increasing its attack surface and few solutions will compensate for that. So unless you’re running OTC Linux or similar as your corporate desktop then you will need to treat each one as an island to be defended from the waters and not the island itself. BTW, the first op control people should be applying is assuring good identification (what’s undeniably yours vs. what’s not). Without that, you can’t tell the good from the bad in most cases. Also, we did a major investigation and overhaul on sec awareness too. Turns out, it’s done really really wrong. Here’s a presentation I just did on it at RVAsec: https://www.isecom.org/5_Secrets_to_Building_a_Security_Culture.pdf

  11. @Ron To me, SANS 20 is what organizations should do. Sadly, many won’t. The question of this mini-research was to determine the level of true incompetence, not reasonableness. In other words, IMHO SANS top 20 is ABOVE the bare minimum.

  12. @Doug

    >What level of protection does “essential” or “basic” represent, against what threat? I believe an answer to that question is necessary before listing controls and practices

    An excellent point indeed! While this basics idea is not my brainchild, I think the motivation for this was to define the level of true incompetence; thus it would be threat-agnostic. In essence, those below this level will fail to nearly ANY threat :-(.

    However, the type/size of org must *somehow* play into this — we are just not sure how yet.

  13. @Pete, I don’t feel this is ready for ‘order of implementation’ discussion; i expect to argue for at least 3 years about the level of controls considered ABSOLUTE BASICS.

  14. (Full Disclosure, I was associated with SANS and GIAC for many years and still have a role with the graduate school sans.edu, so I am probably biased. That said, do your own homework.)

    @Anton, I agree this is a hard problem. I was mildly optimistic when I heard about the 20 Critical Controls effort: http://www.sans.org/critical-security-controls They are up to version 5 at this point.

    I felt even better when the powers that be allowed a course to go forward, (it is much easier to talk ABOUT something than say HOW TO DO something): http://www.sans.org/course/implementing-auditing-critical-security-controls

    But what really has me excited is the certification and the fact they are building the industry standard way as opposed to one person’s opinion. The Job Task Analysis is going on right now.

    Is any of this perfect? Not even close, but it is a bit like air travel, as incidents occur, we can have a lessons learned phase and make the changes to make flying safer for everyone.

    I tried to believe in ISO 27000, I really did. I got my buddy David Hoelzer to write a class and we gave out a copy of the standards to every student. But they lost their way and got too complex, too wordy, too disconnected from the real work.

  15. @Stephen Thanks a lot for the comment!!

    I love SANS 20 Controls of course, and to me they represent what many orgs should do. However, I won’t say that anybody who does not fully implement the 20 controls is negligent and is being unreasonable.

    However, with this effort, we wanted to look at the “negligence level”, the super-bare-minimum. Maybe I can relook at the Top 20 and see which controls make the bare minimum, and which others are more of the “should do this” variety.



Comments are closed

Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.