We’ve talked a bit about offensive type security: knowing how to attack a system is all well and good. Most penetration testers should know as many of the different ways an attacker can penetrate a system so that they can help build defenses used to slow down the bad guys. This is an integral aspect to Information Security and one that we focus on here at “Hack On A Dime” very much.
However, there’s more to Information Security than just knowing how to attack and defend. Management worth their salt should be able to view their enterprise and be able to visualize how their security plan (as a whole) protects their network. This skill is something that’s crucial to being able to adapt to new technologies and still protect information. And it’s one of the skills that I and my team pride ourselves on building up over the past few years of working together.
Recently, I had a conference call with a client regarding one aspect of Information Security Management: software baselines & procedures. The client was assigned the task of reviewing current procedures for building servers. They had outlined settings that, when a system administrator would build a new RedHat Enterprise Linux 6 server, the admin would follow these procedures to build a server that is compliant with current standards. I say “compliant with current standards”.
It is this aspect of Information Security Management that provides a foundation for being able to provide measurement to vulnerability exposure. Notice how I didn’t say it provided metrics to how secure you are. Why not? Because it doesn’t. Being able to provide visibility to your exposure window for certain vulnerabilities is only one part of an all-encompassing Information Security plan.
This conference call shed light on one of the most erroneous aspects of Information Security mis-management and it’s a topic I thought you, as a penetration tester, and future Information Security Management member, might benefit from hearing about.
Compliance and Standards
The client started the conference call by displaying to all on the call their web-based standards application and first going over some of the more “stringent” standards that they’d drafted up.
And it is here where I, as a consultant, needed tread lightly, because here, as the saying goes, there be dragons. Because the “stringent” standards the client boasted about did, in fact, contain strong terms such as “users will implement encrypted protocols such as ssh or sftp” and yet, at the same time, it contained such wishy-washy terminology as “when the infrastructure can support it”. It was wishy-washy-ness such as this that gives the very human system administrators and users a way out of any restrictions the standards may dictate.
Therefore, restrictions has lost their teeth. The Standards are no longer enforceable by any party that should be given the role of enforcer. No auditor, no management can easily enforce these standards if the rule itself contains a phrase that states “you must do this” … “if you can”. Because the user will claim they can’t. Always.
And yet, I remained quiet. After all, they are the client and the client is always right.
Putting aside the “wishy-washy” verbiage with which the client’s Standards were crafted, let’s look at what they actually state. The client was required to be compliant with Payment Card Industry Data Security Standards or PCI-DSS. The client’s Standards & Policies reflected their desire to be compliant with the PCI Data Security Standards. The restrictions that the Standards dictated, demonstrated a desire for their systems to be less wild and insecure and more in line with other systems that are compliant with PCI DSS requirements.
While the task at hand was to review the procedures to build new servers and ensure they are still compliant with PCI DSS requirements, I, as an experienced security expert, saw that while the procedures did a good job of mapping out compliance to the PCI DSS requirements, it nagged at my very being that what was being laid out for this client as a baseline for building secure servers, was, in fact, a minimal set of security settings, at best.
“Real World” Security vs “Just Okay” Compliance
The client’s standards spoke of setting warning banners to proclaim loudly, “Attacker! This computer is not your computer! By accessing it, you may be prosecuted!”. The client’s standards spoke of turning of telnet and FTP (unencrypted protocols that any network sniffer could capture) and ensuring that use of SSH and SFTP (encrypted protocols) was turned on.
However, basic “real world” security settings were completely and utterly ignored. For instance, it isextremely well known that SSH version 1 has many vulnerabilities, it is a basic “real world” defense to configure all SSH servers to explicitly forbid fallback to SSH V1 communications. This is a quick setting that would take a moment to configure on any current SSH server.
So, for all the loud proclamations via setting a warning banner, nearly every server that answers SSH, allows a client to “downgrade” their communications to SSH V1. So, very nearly all their SSH servers were vulnerable to attack via exploits that were over ten years old.
When is Too Little Not Enough?
In this conference call, I brought up to the client the fact that their “stringent” Standards were somewhat lacking in their strength when it came to “real world” security. Very gently, I illustrated a few of the settings that the Center for Internet Security outlines in their SecurityBenchmarks and asked if the client wanted myself and my team to review the procedures for compliance and at the same time, review the CIS Security Benchmarks to produce for them a list of deltas that could be implemented to bring their baseline procedures up to a more secure plateau.
I was told “thank you, but no.”
And herein, lies the problem with most corporate security plans. This is the crux of why even the most “secure” facilities fall prey to attackers. Why do corporations who should know better get hacked on a nearly monthly basis? Because the corporate sector touts how “secure” they are by confusing the concept of security with the concept of compliance.
The two things are so incredibly diverse, as to be very nearly two separate thought processes.
Conclusion
What Information Security Management should realize is this simple concept: Being compliant with regulations and requirements should be a by-product of implementing a good, strong, security plan. All corporate entities should do the most they can to implement strong security and ensure that a subset of THAT security provides compliance with regulations.
Unfortunately, too many corporations ensure that they have done the least they can possibly do (the utmost minimal) to be compliant and constantly ignore the challenges they need to overcome to be truly as defensive as they possibly could when it comes to security.
If you’re going to be entering into the Information Security Management realm, understand that you need to be the preacher when it comes to implementing security over compliance.
