One of the great things about being on the security assessment team is the ability to work with companies to truly improve their overall security posture. Sure, it’s interesting to talk about zero-days and exotic exploits against systems they don’t have, but in most cases, it doesn’t hold particular relevance.

Part of our assessment exercise is to not only find vulnerabilities, but to be able to demonstrate that the vulnerabilities we’ve discovered have significance to a given company. This helps IT departments decide where best to assign resources so they can, to borrow a cliché, get the most bang for the buck.

In the course of carrying out our assessments, I’ve always found it interesting that many folks have the same issues that many of their IT brethren face. On one hand, this is perhaps a bit discouraging – seeing the same vulnerabilities across numerous companies to me means the security industry is doing a relatively poor job of finding ways to close off common avenues of attack, or at least convincing people to do so.

However, it also affords the opportunity to take advantage of a common pool of knowledge. After all, there is some comfort in knowing other people are trying to solve the same problems that you are.

So what are some of these problems? I decided to come up with a list of five of them that we see frequently, and propose some solutions that perhaps can be done to start solving them within your own organization. For your consideration, and in no particular order, here are five things you can do to improve your security. Interestingly, most of them don’t even require you to purchase a single item.

Fix your passwords.

To be fair, this is a big topic, but it’s probably the number one way we end up compromising systems. First, develop and enforce a password policy. Most folks know about the need for long, complex passwords, but we’ve found that a simple change in phrasing can be very effective. Consider changing “password” to “passphrase” when talking to users.

Modern authentication systems can typically handle spaces, punctuation, special characters and significant length. By reminding users to use a passphrase, it discourages people from choosing something easily guessed (I’m looking at you right now, Spring14), or something so convoluted they need to write it down.

As an example, “+I love my dog Sparky.+” is a decent passphrase, and may be easier to remember than “SD7034h20DSsd.” It also makes it easier to enforce much longer passwords (15 character passwords are great!) without having to face nearly as harsh a backlash from angry users who can’t remember their current 6-character password.

Secondly, perform a periodic password audit. Free tools such as fgdump can be used to extract password databases from Windows systems, while open source password crackers like John the Ripper can crack them. In this case, you aren’t worried about cracking ALL the passwords, but finding out which are the weakest. (You’re probably going to be surprised by the result!)

Finally, work toward password/passphrase isolation. By this I mean not reusing a password in more than one security context. (The term we like to use is “implied trust relationship”). If you have a Windows and iSeries environment, each with a separate login, choose a unique password for each. We very often get into more secure environments by compromising a weaker one and simply reusing credentials. We call this the weakest link phenomenon. To tie into this…

Use a password safe.

Too many people still have a spreadsheet or Word document of important passwords saved somewhere. One of the first things we do once we get on a network is locate such things. Even password-protected, these documents are at risk of compromise – some vendors even claim that they can crack these protected documents “almost instantly.” Whether or not this is true is unclear, but the risks of password compromise on such platforms are worth taking into account.

Rather than using formats not necessarily designed for protection, password safes such as Keepass offer simple methods of protecting sets of passwords using various means. In the event that a more comprehensive multi-user based solution is required, some vendors also have enterprise-grade password vaults to help manage more complex environments. Using a password vault will make it easier to have unique passwords across systems, while maintaining the security of said passwords.

Egress (outbound) filtering.

There is almost no reason to allow ports 139 and 445 from your internal network to a host on the Internet. So why do it? We use this flaw frequently to exploit environments from the Internet, which may give us a foothold in your internal network.

Attackers can also more easily exfiltrate data from a network without you seeing it – the fewer options you give them, the more likely it is you can detect anomalous traffic. This requires developing a sense of what sort of traffic you need to allow, which can sometimes be an annoying task, but the benefits will ultimately win out.

Incidentally, very strict egress filtering on traffic from “secure” networks (like a Payment Card Industry (PCI) environment, for example) has a real tendency to slow us down and increases the amount of time we have to spend in a heavily-monitored network. We’re more likely to be caught in that scenario. We don’t like when that happens, and you can bet attackers don’t, either.

Improve your monitoring.

I am always a little saddened when we create a domain administrator account in an environment (that’s the equivalent of planting your flag on the top of a hard-climbed summit, I suppose) and the company never notices. Creating a new domain administrator account is about the biggest warning flag out there, and we’re announcing our presence like few attackers probably would. To not be able to detect that and respond to it indicates that monitoring (and alerting) could probably use some improvement.

This is a hard task, no question about it. Like egress filtering, it relies on developing baselines as to what constitutes normal behavior and then deciding on rules that alert you to something being wrong. In our case above, a simple event driven rule stating “text me immediately when a new domain administrator is created” could be crafted. Securing resources often boils down to being able to detect when someone has managed to get in, and keeping them slowed down enough to respond before significant damage can be done.

Perform routine scanning.

Donald Rumsfeld famously uttered a quote about known and unknown unknowns. (That breaks my brain just writing it.) But ultimately, part of his point (I think) was that we can’t make decisions when we don’t know what the scope of the problem is. The same is true of security vulnerabilities – it’s difficult to defend against problems you don’t know exist. To that end, performing regular internal vulnerability scans is a great way to become more aware of your threat landscape, and then make some decisions as to how to react. It’s also far more cost efficient.

If you find that many of your vulnerabilities can be remediated with a better patching methodology, then that may be a lot cheaper than investing in agent-based sensors to determine when someone has broken into your important assets. It’s not to say sensors on critical systems are bad, but are you solving the core problem? Without regular vulnerability scanning, it’s difficult to say. Such scans can be conducted internally on a regular basis, which has the added benefit of spotting trends. Some companies scan every 30 days to really have a sense of what’s changed.

We are also fans of having periodic third-party assessments such as the ones we at CDW perform to help validate those findings. Keep in mind, a fresh perspective is likely to see your environment completely differently, and may offer valuable insight as to threats you had not considered.

This is certainly not a comprehensive list, and any one of these five points could be discussed at far more length than I have here. I hope however that I have given some insight as to things we frequently find to be problematic in many of our engagements. If nothing else, giving some thought as to how your own organization is dealing with some of these topics might help to drive the security discussion within your own organization. We may work at unique companies, but at the end of the day, we’re all largely in the same security boat.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

This site uses Akismet to reduce spam. Learn how your comment data is processed.