Support • (786) 621-8600 Contact us

Recent Posts

Author Archive


Guest Blogger, Sean Slattery

Sean Slattery is founder and CTO of Caribbean Solutions Lab, a boutique cybersecurity firm and longtime partner of Digital Era Group. A 25 year veteran of the IT industry and former security instructor, Sean oversees their managed cybersecurity services.

Tales from the Trenches – S01E03

Falling victim to Ransomware

Hello again! In our last episode, we talked about some cybersecurity fundamentals, particularly knowing what is connected to your organization. In these tales, we’re going to continue with this thread which should stress the importance of this topic.

This is the tale of a relatively recent ransomware incident. If you aren’t familiar with ransomware, it is a type of malware that encrypts your data or system and promises the decryption keys once a ransom is paid. The value of the ransom is typically proportional to the amount of data held hostage and usually paid by bitcoin. Sometimes the keys are not given or don’t work after a ransom has been paid and sometimes, organizations held hostage have been able to negotiate the amount to be paid.

I don’t know all the inside details of this incident but was informed of the issue by another organization who likely heard of it because the cybersecurity world is quite small. Likely, they might have been warned by a conscientious peer. A check of the victim organization’s web site did confirm an issue with their systems and business interruptions. Again I called my peers to learn more and found out that there was indeed a ransomware incident. The victim organization had the basic tools in place but were lacking in a critical area; if you guessed knowing how many computers were running in their organization, you would be right. Somehow the various IT and security teams only ever expected a certain number of computers in the organization yet the reality was that they had many, many more. And due to the way their security management tools and policies were configured, their systems were left unprotected and highly vulnerable. After what was undoubtedly a costly incident response effort, the organization did recover and resume normal operations.

In a perfect world, HR, IT, security, inventory, license and change management process are all in sync with birds singing and unicorns jumping over rainbows. But that’s a perfect world. Life happens. If you can’t rely upon a centralized or coordinated process, there are still ways to address the topic and minimize your risk. Let’s start with your typical AV security management system. Most modern security management systems can poll or sync with Active Directory (does anyone use Novell Netware or Banyan Vines anymore?!) Simply polling AD twice a day is a good start. Assuming your AD is kept tidy, this technique probably covers 2/3 of your organization with a reasonably small gap between initial management and security coverage. In CPU cycles waiting 12 hours to have protection deployed is an eternity! A good way to complement it with a system that can listen to live network traffic and take automated action. In my favorite security management application, McAfee ePolicy Orchestrator, this is accomplished using the Rogue System Detection system. As the name implies, the modules detect rogue systems (those that are unknown or unmanaged) and take appropriate action i.e., deploy the McAfee Agent. To illustrate how effective this double-layered approach works, let’s look at one organization that had around 2000 Windows endpoints consisting of laptops, desktops, and servers. Through our diligent monitoring and checking of dashboards (recall the lessons from S01E01 of these tales) we found that AV signatures were not as up to date as they should be across the organization. It was found that we only had active management of less than 40% of the systems. They were using daily sync with AD but because they had over 4000 stale computer objects in AD, the daily sync could never run against more than 40% of the system in 24 hours! We implemented RSD and within an hour achieved over 80% coverage and over 90% by the next day. It turns out that the desktop teams where never deleting the old AD computer accounts when reimaging/redeploying the systems resulting in a gradual stockpile of legacy computer objects.

There are other options. You could use AD to deploy the necessary agents and apps for you. You could also use a 3rd party tool to monitor and alert you to rogue systems. The Spiceworks app is a great, free tool that has this capability. Your mileage will vary of course depending upon your organization’s particulars but it is well worth the effort.

Until next time, be safe out there!

Tales from the Trenches – S01E02

Know Your Enemy but Know Yourself First

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle” – Sun Tzu, The Art of War

No self-respecting cybersecurity article would be complete without at least one Sun Tzu reference and if you have spent any time in the industry, you will have heard this mantra several times. At the recent Secure Miami conference, there was a great discussion on career opportunities within cybersecurity. As usual, the sexy, tier 1 roles like ethical hacker and penetration tester got the limelight. It is in this context that this Sun Tzu quote is usually applied. You need to understand how the enemy thinks in order to be better prepared. I won’t disparage the value of these roles however, I’m going to share an alternative, yet the equally important application of Sun Tzu’s adage.

The following tale focus on knowing yourself. These two incidents happened nearly ten years apart with different organizations. Both organizations fell victim to malware. In the older case, the malware created a denial of service condition rendering the Windows systems inoperable. In the more recent case, the malware in question was a form of ransomware and rendered the infrastructure inoperable and extorted the organization for their own data.

This first story has two parts and goes back a few years – to a kinder and gentler time when malware was less malicious! It started when a customer called me about some malware that had infected a couple of systems. I rolled out and we quickly determined that it was a new strain that was not yet detected by the antivirus signatures. It was, however, spreading rapidly across the local network. This was evidenced by the infected systems becoming very slow. We immediately shut down the WAN connections, particularly those to other countries. Within an hour we had an emergency AV signature file from our vendor and began the deployment. As we had all hands on deck to assist with this location, we also made a point of walking to each office and ensuring that the computer was updated, rebooted and an explicit AV scan performed of the local drives. We all know that new malware surfaces daily, but the puzzle was how it managed to spread so quickly, in particular from workstation to workstation. After a bit of digging, we discovered that the Windows Domain Users group was made of a member of each computers’ Local Administrators group. It was and is still all too common practice for IT administrators to take this shortcut and grant users administrative rights. The result of this shortcut was that the source of the infection, a single user, was able to infect every workstation in the local office! Had administrative rights not been granted, the infection would have been contained to that computer and the user’s connected network shares. Within 12 hours, we had the incident resolved with no loss of data or reputation to the organization. As part of the after-action plan, we began implementing a relatively new file-reputation add-on to their AV that reduces the risk of new malware impacting systems before the vendor can develop, test and release signatures.

The second part of this tale actually occurred in parallel. During our initial investigation, I called some peers to see if they had recently experienced anything similar. As it turns out, one of my peers was also in the midst of an incident response and for the same malware! This organization had recently deployed, the previously mentioned, file-reputation add-on. Most of this organization was protected and was actively alerting security administrators as to the source of the infections. The problem was that the source of the infections was a set of computer labs, previously unknown and undocumented. These labs were funded out of a separate budget and connected to the organization’s network – all without ever informing central IT or security. As a result, the organization standard security policies and tools were never implemented. Eventually, through clever use of a host intrusion prevention system, the infections in the labs were contained and the systems cleaned and secured.

If you have attended one of my classes, workshops or seminars, you will know that I am a great fan of keeping things simple. The simpler it is, the easier it is to understand, manage, troubleshoot and document. When it comes to cybersecurity, focusing on infrastructure, here are five simple questions or points to address:
  1. What is connected to your organization?
  2. What is running in your organization?
  3. Who has administrative rights?
  4. How is your organization being monitored?
  5. How do your various tools work together for correlation, integration, and automation?

Tales from the Trenches – S01E01

The Value of Checking Your Work

Cast your mind back to your school days. Do you remember being told to check your work? I do and the story I’ll share with you here is a great illustration of the value of checking your work or alternatively, having your work checked. We’re humans and not infallible. Mistakes will be made. The important thing is to learn from the mistakes and not repeat them.

For many years I was a security instructor. I would typically fly to an island and teach class for a week and then fly home. Sounds glamorous right? It was rewarding and the personal and professional connections I made are still with me to this day. It was also quite tiring and the funny stories of traveling and working while exhausted will have to wait for another time. Anyway, the classes were run on labs using local virtual systems running on student supplied hardware. Many times, I taught using course ware and labs of my own design but often I needed to use the official curriculum. In order provide a relevant context to the lessons, I encouraged students to follow along using their own systems. I would also provide a complimentary health-check of their environments. That is, I would take a quick look at their security management dashboards and reports and see if I could identify any issues or make recommendations for improvement.

This story takes place during one of these classes, when a student, let’s call him S, asked me for a health check. For reference this class covered the installation and use of the central management and endpoint security applications. S shows me his management console and the first thing I notice is there are zero threat events. Not a low number of events but none! For 200+ systems, even a perfectly tuned environment is going to show something, unless they’re discarding data. S proudly says to me that they don’t have any security issues or events, just look at the dashboards! I challenge him on this asking if he allows direct Internet access, email, email attachments, and removable device usage in the organization. He does so I challenge him that there just has to be something happening. I even went so far as to say that I would give him $100 out of my own pocket if the information was truly accurate!

I roll up my proverbial sleeves and dive in. The first thing I noticed was that the Windows system on which the central management server was installed did not have any endpoint security software installed. He questioned why that mattered. The management software was just for management and the system still needed the security software. So I manually installed the endpoint security software as per their standards when we notice some stability and performance issues. We, of course, had backups of their policies and other key files. A bit of digging revealed that they were using an old build of the endpoint security software. By old, I mean a version that released well before the version of Windows server in use. We applied the necessary patch and rebooted the system. I pointed out that they needed to keep their security software up to date along with everything else in the organization.

Guess what the dashboards looked like after the reboot? If you guessed that it lit up like a Christmas tree, you would be right! It turns out that the management software had lost connectivity with the SQL database over three months earlier. Rebooting the server enabled the re-connection and all endpoints began reporting their events. Thankfully, the deployed endpoint security software was resilient enough to detect and mitigate the various threats as well as update signature files in the absence of a functional central management system. You’re probably wondering what kinds of threats they were seeing. There was plenty of spyware and adware as well as removable media-based Trojans. After the understandable surprise, we worked together to ensure that they were deploying the latest appropriate version of the endpoint security software and demonstrated how to test the systems to prove that the systems were operational.

Lessons learned:

  • Check your own work. If you manage to reach a point with policy tuning where things are very quiet, run some test files or activities through your systems. Ensure that you receive the alerts and that the events show up in your scheduled reports. You are scheduling reports, aren’t you?
  • Have your worked checked by someone knowledgeable in the technology in question, not just an auditor who asks you to show your work.
  • Your security tools need to be updated just like your operating systems and business applications.
  • Don’t be afraid to ask for help. No one has dealt with everything or seen every possible situation. Develop a peer group and collaborate. As a group, you’ll be better off than trying to go it alone.
by Guest Blogger Sean Slattery

About the Author:

Sean Slattery is founder and CTO of Caribbean Solutions Lab, a boutique cybersecurity firm and longtime partner of Digital Era Group. A 25 year veteran of the IT industry and former security instructor, Sean oversees their managed cybersecurity services.