I am a very sharing kind of guy and firmly believe that sharing is caring. I am happy to share absolutely anything and everything, with literally only two exceptions. I am not big on sharing my toothbrush, and I absolutely do not share my passwords under any circumstances. There are two kinds of password sharing that I am totally against. The first is sharing a password between sites. I make sure every site I have an account on has a totally unique password. This means that my password for Facebook, Gmail, Twitter, my bank, etc., have nothing in common. If there is a single character in common, it would be a random fluke.

The second type of sharing I am against is sharing passwords with anyone else. No one has any of my passwords, not even my spouse, absolutely no one.

Before you start to ask about “but what about …” I will provide a blanket answer. I am just making the rules and providing guidance. Whether you follow them is on you. I will try to explain the reasons, so you understand the risk. You understand your risk model the best and can best judge if taking that risk is worth it to you. If you need help with your risk model, I have another article on that.

You are probably thinking to yourself, that sounds like a lot of passwords to keep track of, and you would be correct in that thinking. I have several hundred passwords in active use. How do I keep track of all those passwords, you ask? Do I have them all memorized? Absolutely not. I am lucky if I can remember two passwords. I use a password manager to keep track of my passwords.

A password manager is an application that is specifically designed to track passwords securely. Care needs to be taken when choosing a password manager. Many applications out there that claim to be password managers and may even operate like one, but in reality, are malware design to harvest all your credentials. Make sure to choose one that fits your needs, is well respected, and well known to be highly secure. When looking for a password manager, look for the following:

• Strong data encryption, ideally using at least AES 256-bit level of encryption or stronger
• Multifactor Authentication (MFA). The best ones offer multiple options to choose from
• Is the solution monitored for access, data corruption, and operational issues?
• Can you access the password manager anytime and everywhere you need to?

One example to look at is a product called LastPass from LogMeIn.

I know I promised you details behind my recommendations, so here goes. When you use the same passwords on multiple sites, all the sites that use the same password are compromised if one of those sites is compromised. This can become a massive headache. While maintaining 100’s of passwords is a bit of pain, it is nowhere near the pain of changing passwords across hundreds of sites when one of those sites has a cyber incident. Also, having data from one site in the hands of cybercriminals is bad enough. Enabling them to access ten sites because they all share the same password is ten times as bad.

Another thing regarding password management that is important is choosing a good password. In the past, there was a lot of talk about the complexity of the password being essential. Passwords needed to have upper case, lower case, number, and a special character. This ended up everyone choosing something like Fall2020! as their password. This is a horrible password and can be breached in a fraction of a second. The US National Institute of Standards and Technology (US NIST) even recanted earlier advice on this and has totally changed course in their account management standard.

Recent research shows that length is the most important aspect of a password. Do not think of a password as a single word, instead as a phrase that is at least 15 characters long. I try to make all my passwords at least 20 characters long. Many password managers also have a password generator function that will generate just a random string of characters. This is most secure but impossible to remember. Since I am using a password manager, 99% of my passwords are randomly generated and stored in my manager.

For a more memorable phrase, think of a phrase that no one is likely to guess. Avoid site or app name and well-known aspects of you or your life. It is a plus if it is not grammatically correct or even does not makes sense. Something along the lines of “NittingCowDancesMoon!” would be a good password except for the fact that it is published here as an example. It is both strong because of length and matches complex rules for sites that are still stuck on the old advice of password complexities. Feel free to experiment with spacing, punctuation, etc. Sites and applications vary greatly in what they allow in a password. The most secure ones have no restriction, except for not allowing short passwords.

That is it for this installment. As always, feel free to reach out if there are questions.

This article was written with companies in mind; most of this applies to individuals as well. Most security incidents happen due to phishing, and I have a sure-fire way to avoid becoming a phishing victim. Just do not click on links in email or open attachments. Yes, I do realize that this advice is about as useful as telling someone to stop smoking or not eat donuts. It is a lot easier said than done. Also, any suggestion that starts with the word “just” tends to be suspect. Hear me out, though, as I explain how this could be implemented.

This needs to start with a culture of not sending unexpected links or attachments around. There needs to be an internal document repository site, which is automatically a part of everyone’s bookmarks. Rather than attaching a file or sending a link to it, in the email, describe where it can be found on the internal site. Something like “the document can be found under documents -> ProjectX -> design.”

This way, people will fall out of the habit of clicking on links or open attachments, and it will start to become abnormal and strange to do so. Emails offering free ice cream and the like will continue to be tempting because human beings love games, contests, and most of all, free stuff. If you set up an internal contest about finding malicious emails and notifying the security team, that could satisfy that urge, especially if free ice cream is the reward.

Rather than training folks in deciphering URLs and determining if the link is valid or not, make the training situational.

• They are signing up for a service that requires providing their email address, and the sign-up process says a confirmation email is being sent, and you need to click on it to confirm the registration. If you get an email within a few minutes that looks like it is from that organization, then clicking on that link carries a relatively low risk.
• They are on a conference call. Someone on the call says they are sending a document to everyone. They explain what it is all about and why it needs to be sent around rather than posted to the document repository. When you get an email from that person that matches the description, opening it carries a relatively low risk.
• If they receive an email with a link or attachment that does not match either of those scenarios, claiming to be from an internal contact or other known contacts, look up their contact information in the internal company contact list and call them up or send them a chat message asking them what this is about and why they choose to send it in an email rather than post it on the document repository. If they get a satisfactory explanation, the risk of opening it is low. Never reply to the email or use other contact information in the email. If alternative contact information is not available outside of that email, consider the email malicious. If the explanation for the email seems off or sketchy or the sender seems sketchy, the safe move is to consider the email malicious.

Additionally, it would be a good idea to train everyone in the hallmarks of phishing attempts, which include:

• Trying to scare you
• They are playing on your emotion
• Play up extreme urgency

Ensure all internal processes specify if there is ever a legitimate internal urgent email, that it does not contain links, and simply direct the recipient to an internal site. All internal announcements should be posted on an internal website as well.

This post is going to be more applicable to companies than individuals as it is going over how to manage vulnerabilities across all your computer systems. At a super high-level, the concept of vulnerability management is pretty simple. It is all about managing your vulnerabilities. When you dive deeper, then questions start to surface. Questions such as:

• What exactly is a vulnerability?
• How do I know what my vulnerabilities are?
• Can I management something I do not know about?

Some think that vulnerability management is all about having vulnerability scanners such as Tenable Nessus or Qualys and periodically running scans with them. Others believe it involves periodic penetration testing. Not only is this extremely flawed thinking, but it is also potentially dangerous and increases your exposure instead of reducing it. Sure, those things can add value to an already mature vulnerability management program; at best, they are a small addition to an overall program.

The purpose of a good vulnerability management program is to reduce your exposure and make it easier for you to respond when an issue comes up. To answer the questions from above, you cannot manage something you do not know about. To define the word vulnerability, turn to any English dictionary; it will give a good definition applicable here. The third question will require some discussion.

Since you cannot manage, what you do not know about a good asset and configuration management is the foundation of a good vulnerability management program. If you can only do one thing, just get your hands around what you have. This, of course, starts with knowing what computers and systems you have where, what IP addresses they have, and who is responsible for them. Knowing how big the hard drive is, how much memory it has, and what sort of NIC it has is not critical to vulnerability management, but it is useful information for other programs. Knowing the MAC addresses could come in handy, though, for this discussion. Once you have the basics covered, it is time to dive deeper, this is often called configuration management, but it is just an extension of asset management. In this stage, you collect details about what is installed on each computer. Here you capture things like

• What Operating system is installed, what version, and when was it last patches?
• What applications are installed, what version, and when was it last patched?
• What frameworks are used by what application?
• Do any of the frameworks or applications rely on external components or modules?
• Is any of this managed by someone other than the system owner?

Notice a trend there? For good asset and configuration management, all this and more should be documented in excruciating detail. If done correctly, you should be able to pull up all the systems that have a specific version of dotNet Framework, or a particular version of python, etc. You should also be able to detail the exact specs, all installed applications, frameworks, etc., for a given IP address or hostname. Make sure you capture both, along with any aliases and domain names.

Once you have all this documented, it is time to turn to the process side.

• How will you stay informed with issues that come up in the industry?
• Who is going to watch announcements from US-CERT, NIST, NVD, etc.?
• How will you go about remediating issues as they are discovered? Who will have what role? How will information flow?
• Publish a statement on your website on how a security researcher can notify you of an issue they notice externally. Then have an internal process for handling these notices, who is responsible for what, etc. This is called the responsible disclosure process.

Now you can say you have a vulnerability management program. Notice how there is no tool involved so far. The only tool you might think about so far is a Configuration Management Database (CMDB). If you are small enough org, you can do all of this with nothing more than your standard Office suite that you likely already have. If you are a little larger, a proper database will make a world of difference.

Only after you got both a solid Configuration Management and a firm policy & procedure should you even think about bringing in a vulnerability scanner. At this point, you can start to look at products like Tenable, Qualys, Tripwire IP360, etc., and find a product that suits your needs. Feel free to reach out if you need advice in this space. Then amend your existing Vulnerability program with details around what should get scanned when and who is responsible for what. Make sure you specify who is responsible for making sure scanning happens, who is responsible for disseminating the scanning results, and who is responsible for remediation.