What to Do When You Gotta Have FTP

FTP has been around for a long time. While it has grown long in the tooth, it continues to be an essential protocol for many business processes – especially in the financial industry. Clearly, it is a functional and useful tool, but it certainly also comes with significant security risk.

First of all, in its bare form, it is a plain-text protocol and open to capture and observation by anyone in the communications path. Firewall rules pertaining to its different modes of operation are also often confusing for novice network techs and admins, sometimes leading to inadvertent security issues in its deployment. Worse yet, it is a commonly scanned, brute forced and exploited attack surface as well.

But, if you are any of the industry firms where FTP is still a mainstay (banking, wealth management, title management, loan processing, imaging, etc.) how can you do your work and still try and keep security as tight as possible?

Let’s start with identification. You need to know if you have FTP exposed to the Internet, partner networks or on any segments where trust is low. For each instance, you need to understand the data that is being moved, the sources and destinations of that data, the authentication mechanism and model in play (you’re using strong passwords and MFA, right?) and you need to carefully consider the trusts that exist within the system and network environment where the server lives.

Then, you can address prevention. Do you have an alternative to replace it with SFTP or another encrypted protocol? Does it have to be exposed to the world, or can you use access controls or restrict the source IPs allowed to connect to it with either host configurations or firewall rules? How is the server component kept updated to ensure that patching is taking place?

Let’s talk detection. Are logs being generated, stored and reviewed? How would you know if a brute force attack had exposed your data or credentials? How would you identify malicious behavior against the FTP service? Many companies we talk to (especially smaller ones), don’t have good plans for monitoring these systems, even though they may be mission critical.

If something bad happened, you should also have a response process in place for managing FTP data. What would you do if the data were compromised? What would you need to do if the FTP server were not available or the network was down for an extended period? Running table top exercises is usually a good way to develop and refine the policies and processes needed around FTP data exchanges.

Lastly, your organization should have a plan for recovering from problems with the FTP server. Is the data backed up within an appropriate window and how would/could that data be restored? What would be the business and financial challenges to recovery? How would you handle notification of partners or customers that were impacted?

These are pretty basic questions for infosec teams, but for many organizations with more ad-hoc IT staff or for smaller organizations with only contractors they can be daunting. 

Hopefully our advice above gets you thinking about FTP. As always, if you have questions or need assistance executing any of the above – MSI is here to help. But, if your team takes this list and executes against it – you should be much better off than before the project began.

As always, thanks for reading, and until next time, stay safe out there! 

Prescription pharmacy bags – do you just trash them?

When you get your prescription filled at a pharmacy, the medication is usually dispensed in amber colored pill bottles packaged in a pharmacy paper or plastic bag. Once the medication has been consumed, many discard or recycle the bottles.

There have been several articles on how to remove the sensitive information contained in the medication labels on the bottles. The information include the patient’s name and address, name of doctor and medication details. Recommended methods of removing the information include striking them out with a marker pen or removing the label. Some locations will accept the bottles and remove the labels and information for you, and recycle the bottles.

However, nothing is said of the pharmacy paper or plastic bag that the pill bottles come in when you get them from the pharmacist. When I get my meds from the pharmacist – from a big name national grocery store – I am asked for identification to receive them. I am asked of my name and phone or birthdate, and they verify with the information printed on the bag.

Most people are not aware of or don’t consider the information on the front of these bags. The information can be much more sensitive than what’s on the pill bottle labels. These bags are thrown in with the trash, never shredded. That leaves the information vulnerable to dumpster divers and identity theft.

The pharmacy bags the big grocery store dispenses the prescriptions in are sealed plastic bags. I can’t shred them so I stretch and tear the plastic to destroy the information. Most people will not take the trouble to do that. I have spoken with the pharmacist at the location I pick up my medications at with my concerns. Their process is obviously not up to him but perhaps he could pass on the concerns.

Take note of the label information your medications come in, not just the pill bottles but the pharmacy bag. Your private information is not only on the pill bottles but on the bag when they hand you your meds. Dispose of these packaging appropriately.

 

Resources:

http://rxoutreach.org/education-understanding-prescription-medication-labels/

https://www.popsci.com/old-medications-prescriptions-disposal

There’s Still Treasure in the Trash

Most businesses have processes and policies for handling sensitive data on paper, whether thats selectively shredding papers or shredding everything, along with training about what goes in trash bins and what goes in shredding bins. However, how many are ensuring that these policies and processes are being followed? Brent asked

Which got me thinking about this. I couldn’t remember the last time an organization actually asked us about it beyond reviewing policies. I know this problem didn’t disappear, even as we move more and more away from paper. Paper still gets used, people write stuff down, things get printed, and no solution completely ensures that that paper doesn’t end up in the wrong bin. I know from doing it. I found something useful in almost every engagement that we’ve done in the past, whether it was an administrative password, or contact information that I can use for phishing.

Recently, some researchers performed a trash inspection of some hospitals in Toronto. What they found didn’t surprise me. They found PII and PHI, a good bit of it.  A resident in Palolo Hawaii found these too. A nuclear security complex was found to be dumping trash that had classified documents in it. None of these were reported breaches, just there for the taking. Who knows if anyone malicious found them too?

Let’s keep working on the most prevalent topics of the day, such as phishing defense and training, but we can’t forget all of the things that were an issue in the past, because they’re still an issue now even if they’re not making the big headlines in the current moment.

That phone call you dread…

So, you’re a sysadmin, and you get a call from that friend and co-worker…we all know that our buddies don’t call the helpdesk, right?

This person sheepishly admits that they got an email that looked maybe a bit suspicious in hindsight, it had an attachment…and they clicked.

Yikes. Now what?

Well, since you’re an EXCELLENT sysadmin, and you work for the best company ever, you’ve done a few things to make sure you’re ready for this day…

  • The company has had a business impact analysis, so all of the relevant policies and procedures are in place.
  • Your backups are in place, offsite, and you know you can restore them with a modicum of effort – and because you’ve done baselines, you know how long it will take to restore.
  • Your team has been doing incident response tabletops, so all of the IR processes are documented and up-to-date. And you set it up to be a good time, so they were fully engaged in the process.

But now, one of your people has clicked…now what, indeed..

  • Pull. The. Plug. Disconnect that system. If it’s hard wired, yank the cord. If it’s on a wifi network, kick it off – take down the whole wifi network if feasible. The productivity that you’ll lose will be outweighed by the gains if you can stop lateral spread of the infection.
  • Pull any devices – external hard drives, USB sticks, etc.
  • DO NOT power the system off – not yet! If you need to do forensics, the live system memory will be important.

Now you can breathe, but just for a minute. This is the time to act with strategy as well as haste. Establish whether you’ve got a virus or ransomware infection, or if the ill-advised click was an attachment of another nature.

If it’s spam, but not malicious:

  • Check the email information in your email administration portal, and see if it was delivered to other users. Notify them as necessary.
  • Evaluate key features of the email – are there changes you should make to your blocking and filtering? Start that process.
  • Parse and evaluate the email headers for IPs and/or domains that should be blocked. See if there are indicators of other emails with these parameters that were blocked or delivered.
  • Add the scenario of this email to your user education program for future educational use.

If it’s a real infection, full forensics is beyond the scope of this blog post. But we’ll give a few pointers to get you started.

If it’s a virus, but not ransomware:

  • If the file that was delivered is still accessible, use VirusTotal and other sites to see if it’s known to be malicious. The hash can be checked, as well as the file itself.
  • Consider a full wipe of the affected system, as opposed to a virus removal – unless you’re 100% successful with removal, repeated infection is likely.
  • All drives or devices – network, USB, etc. – that were connected to the system should be suspect. Discard those you can, clean network drives or restore from backup.
  • Evaluate the end user account – did the attacker have time to elevate privileges? Check for any newly created accounts, as well.
  • Check system and firewall logs for traffic to and from the affected system, as well as any ancillary systems.

If it’s ransomware:

  • Determine what kind of ransomware you are dealing with.
  • Determine the scope of the infection – ancillary devices, network shares, etc.
  • Check to see if a decrypt tool is available – be aware these are not always successful.
  • Paying the ransom, or not, is a business decision – often the ransom payments are not successful, and the files remain encrypted. Address this in your IR plan, so the company policy is defined ahead of time.
  • Restore files from backup.
  • Strongly consider a full wipe of the system, even if the files are decrypted.
  • Evaluate the end user account – did the attacker have time to elevate privileges? Check for any newly created accounts, as well.
  • Check system and firewall logs for traffic to and from the affected system, as well as any ancillary systems.

In all cases, go back and map the attack vector. How did the suspect attachment get in, and how can you prevent it going forward?

What are your thoughts? I’d love to hear from you – lwallace@microsolved.com, or @TheTokenFemale on Twitter!

You backed it up, right?

Yes, folks…we’re back to basics here. Anyone think we’d still be talking about this in 2018? We are…

Our recent incident response work has brought this to the front of my mind. Think for just a minute about a company who has a business vs. technology conflict. They want their backups to be QUICK! So they put their backups on a NAS. Network attached storage.

Key word there – attached. Now, let’s role play that they have been hit by ransomware. They can restore their backups quickly…and now they’ve lost their backups quickly as well. How catastrophic would this be for you?

There are several things to think about when it comes to your backup strategy. First, what do you need to protect against?

  • Natural disasters. Onsite backups are convenient, but not terribly convenient if your whole building burns down. Are you in an earthquake zone? Tornadoes? Hurricanes?What kind of catastrophic happenings could you experience, and how far away do your backups have to be to be protected?
  • Risk from external attackers. Going back to our ransomeware scenario above, what’s the balance between ease of restoring backups vs. protection from harm for your organization?
  • Risk from internal attackers. We all want to trust our sysadmins. What happens if one of them is disgruntled? What safeguards are in place to protect your backups from internal threats?
  • Testing your backups. Periodically perform testing of your backups, both inside and outside of an incident response tabletop. Make sure that your backed up data really IS backed up, and restores in the manner you’d expect. This is a good time to create some baselines on the restore process, as well – what’s your time to restoration if a crisis happens?
  • Hot vs. cold disaster recovery systems. How critical is downtime to your business? If hours means millions, you should have – or seriously consider – a “hot” disaster recovery site to minimize downtime as you pivot over.

Backups are routine, and boring…and when things go well, they should be this way. Prepare yourself for the day things do NOT go well, eh?

What do you think? I’d love to hear what I’ve forgotten – reach out to lwallace@microsolved.com or @TheTokenFemale on Twitter.

Micro Podcast – Office 365

With today’s social engineering threats, every company should be evaluating the configuration and security of their Office 365 presence.
Microsoft has provided many robust feature to secure their Office 365 technology.  Many of these features are not enabled by default or they are not enabled by default or they are not enabled with the optimal settings.
For this reason, we created a podcast about potential issues and remediation strategies for Office 365, enjoy!

MSI announces new online store “Small Bytes”

MSI is pleased to announce the opening of our new online Assessment Portal “Small Bytes”!

Small Bytes is an easy-to-use store where you can purchase a subset of MSI assessment product offerings. These are typically quick hit assessments, smaller in scope than our regular product offerings, which allows them to be completed in a relatively short time frame.

  • Targeted Threat Intelligence
  • AWS Configuration Security Audit
  • Office 365 Security Audit
  • Social Engineering – Phishing
  • External Network Vulnerability Assessments
  • Block of Security Engineer Consulting Hours

Small Bytes uses credit cards as a payment methodology and eliminates the need to generate P.O.’s or issue a check to pay invoices.

The only paperwork needed is a one page Customer Order Form (COF) that MSI will send for you to complete after your purchase. This helps to ensure the scope of your engagement and the quality of your results. Please use the link below to check it out!

https://smallbytes.microsolved.com

Thank you as always for choosing MSI to partner with when it comes to your security concerns.

MSI – When quality matters!

Monitoring: A True Necessity

There is no easier way to shut down the interest of a network security or IT administrator than to say the word “monitoring”. You can just mention the word and their faces fall as if a rancid odor had suddenly entered the room! And I can’t say that I blame them. Most organizations do not recognize the true necessity of monitoring, and so do not provide proper budgeting and staffing for the function. As a result, already fully tasked (and often times inadequately prepared) IT or security personnel are tasked with the job. This not only leads to resentment, but also virtually guarantees that the job is will not be performed effectively.

And when I say human monitoring is necessary if you want to achieve any type of real information security, I mean it is NECESSARY! You can have network security appliances, third party firewall monitoring, anti-virus packages, email security software, and a host of other network security mechanisms in place and it will all be for naught if real (and properly trained) human beings are not monitoring the output. Why waste all the time, money and effort you have put into your information security program by not going that last step? It’s like building a high and impenetrable wall around a fortress but leaving the last ten percent of it unbuilt because it was just too much trouble! Here are a few tips for effective security monitoring:

  • Properly illustrate the necessity for human monitoring to management, business and IT personnel; make them understand the urgency of the need. Make a logical case for the function. Tell them real-world stories about other organizations that have failed to monitor and the consequences that they suffered as a result. If you can’t accomplish this step, the rest will never fall in line.
  • Ensure that personnel assigned to monitoring tasks of all kinds are properly trained in the function; make sure they know what to look for and how to deal with what they find.
  • Automate the logging and monitoring function as much as possible. The process is difficult enough without having to perform tedious tasks that a machine or application can easily do.
  • Ensure that you have log aggregation in place, and also ensure that other network security tool output is centralized and combined with logging data. Real world cyber-attacks are often very hard to spot. Correlating events from different tools and processes can make these attacks much more apparent.
  • Ensure that all personnel associated with information security communicate with each other. It’s difficult to effectively detect and stop attacks if the right hand doesn’t know what the left hand is doing.
  • Ensure that logging is turned on for everything on the network that is capable of it. Attacks often start on client-side machines.
  • Don’t just monitor technical outputs from machines and programs, monitor access rights and the overall security program as well:
    • Monitor access accounts of all kinds on a regular basis (at least every 90 days is recommended). Ensure that user accounts are current and that users are only allocated access rights on the system that they need to perform their jobs. Ensure that you monitor third party access to the system to this same level.
    • Pay special attention to administrative level accounts. Restrict administrative access to as few personnel as possible. Configure the system to notify proper security and IT personnel when a new administrative account is added to the network. This could be a sign that a hack is in progress.
    • Regularly monitor policies and procedures to ensure that they are effective and meet the security goals of the organization. I recommend doing this as a regular part of business continuity testing and review.

 

Sunshine on a “cloudy” day…

I recently saw an article targeted at non-profits that was a bit frightening. The statement was that small non-profits, and by extension many businesses, could benefit from the ease of deployment of cloud services. The writers presented AWS, Dropbox, DocuSign, et. al. as a great way to increase your infrastructure with very little staff.

While the writers were not wrong….they were not entirely correct, either. It’s incredibly easy and can be cost effective to use a cloud based infrastructure. However, when things go wrong, they can go REALLY wrong. In February of 2018, Fedex had a misconfigured S3 bucket that exposed a preponderance of customer data. That’s simply the first of many notable breaches that have occurred so far in 2018, and the list grows as you travel back in time. Accenture, Time Warner and Uber are a few of the big names with AWS security issues in 2017.

So, if the big guys who have a staff can’t get it right, what can you do? A few things to consider:

  • What, specifically, are you deploying to the cloud? A static website carries less business risk than an application that contains or transfers client data.
  • What are the risks associated with the cloud deployment? Type of data, does it contain PII, etc.? What is the business impact if this data were to be compromised?
  • Are there any regulatory guidelines for your industry that could affect cloud deployment of data?
  • Have you done your due diligence on cloud security in general? The Cloud Security Alliance has a lot of good resources available for best practices. Adam from MSI wrote a good article on some of the permissions issues recently, as well.
  • What resources do you have or can you leverage to make sure that your deployment is secure? If you don’t have internal resources, consider leveraging an external resource like MSI to assist.

Remember – just because you can, doesn’t always mean you should. But cloud infrastructure can be a great resource if you handle it properly.

Questions, comments? I’d love to hear from you. I can be reached at lwallace@microsolved.com, or on Twitter @TheTokenFemale.

 

It’s OK to save all my passwords in Word, no?

In a follow up to my last blog on password managers, many of my family members and friends have still not picked up on the habit of using them – mostly because of the refused acceptance that there is a small price to pay for increased security; the price being a couple clicks to bring up the password manager app to look up the password for a web site login.

Password managers are still what is recommended to store unique and complex passwords for each authentication/login credentials you may have each domain, computer, web site. But for those family members and friends who have refused to adopt a password manager, I recommend the following.

Instead of saving your passwords in a Word document, save your password hints. We’ll get to how to write these hints later. Save the Word document encrypted, and make the filename something less obvious than passwords.docx – maybe “Favorite Movies.docx.” Depending on PC/Mac version, the encryption feature is found in the Save process under Tools or Options, Security. This is one password you need to remember – make it a good and memorable one.

You may think, Word encryption is not the greatest. True. But this layer of security – encrypting the document with a non-enticing file name – at least keeps the nosey, non-hacker person who might come across your file.

As to what information to keep in the file, you don’t want to store your passwords as-is (in plaintext) in a Word document, even though the file may be encrypted. You should only store information that can help you remember the password. For example, if your passwords are famous movie quotes, to remember the credentials for 2 sites could be saved as:

ebay.com = Clint Eastwood

amazon.com = Jack Nicholson

Each of the above actors has a famous, iconic movie line, and using a consistent transformation method on those quotes, the actual passwords for the sites would be:

ebay.com = gOaheaDmakEmYdaY

amazon.com = yoUcanThandlEthEtrutH

In the above example, the actual passwords are formed by capitalizing the last character of each word in the password hint, and eliminating all spaces and special characters. This transformation process should be memorized and be consistent for all the passwords saved in the Word document.

You can choose whichever transformation process, as long as it’s consistent so you can remember and don’t have to write it down somewhere, eg. capitalize the last 2 characters of each word or capitalize the second character of each word or substitute every first character with a number.

This way, if someone gets a hold of your Word document, and manages to decrypt its password, they will only have a list of password hints, that only you can transform into the actual passwords.

Some other examples of passwords and password hints that you could use:

  • Names of friends and family members, with their birth years as passwords, and the city where they live as password hints, eg.
  • Save in the Word document your password hints:
  • ebay.com = Denver, CO
  • amazon.com = Chicago, IL
  • And from the above password hints, you know your best friend lives in Denver and your aunt in Chicago.
  • Password for ebay.com = JimmyJones1989
  • Password for amazon.com = GertrudeSmith1955

You could even do this:

  • Save in the Word document the following password hints:
  • ebay.com = Go ahead. Make my day.
  • amazon.com = You can't handle the truth!
  • And from the above password hints, use your memorized transformational process, eg capitalize the 2nd character of each word.
  • Password for ebay.com = gOaHeadmAkemYdAy
  • Password for amazon.com = yOucAnthAndletHetRuth

This is “security through obscurity” – much of the information is available but in order for the information to be effective (for the passwords to work), they need to be manipulated using an algorithm that only the user knows but has committed to memory.

You can then email yourself this document. And when you need to look up the password for some site, look up the email, enter the document password to decrypt it, get the info, and use your memorized transformational process to re-construct your password for that site.

This is better than nothing. Better than the alternative of using easy to remember (and crack), simple and the same passwords for all logins. Best to use a password manager, though.

Be safe…

Resources:

https://www.cnet.com/how-to/the-safe-way-to-write-down-your-passwords/

https://www.symantec.com/connect/articles/simplest-security-guide-better-password-practices