This seems to indicate there are some deficiencies in those information security programs, if they had a program at all. I still see a lot of organizations today that don’t have a formal information security program. It usually takes an incident such as ransomware to change an organization’s focus and approach on how they view security, but where do they start?
For the purposes of this blog, l will focus on a fictitious organization as an example. The methodology to build the security program is based on MGT514: Security Strategic Planning, Policy, and Leadership.
PART I
Rekt Casino
Rekt casino recently suffered a breach as the result of a ransomware incident. Under the advisement the incident response firm, and regulators, they are creating a formal information security program. Rekt Casino is urgently wanting to establish security and open the doors again.
Rekt Casino has been in business for approximately 20 years. To this point they have only invested in the very basic technology needs. Security has never been at the forefront. From a security perspective, they are subject to MICS under the Nevada Gaming Control Board. MICS is the Minimum Internal Control Standards for Casino technology.
Rekt has a small IT team of 3 people that serve as help desk, network administration, and server administration. The team tries to secure these systems as they are deployed. Rekt Casino has a very old school approach to information security.
Figure 1: Information Security Evolution
By establishing a formal information security program Rekt hopes to modernize their approach to information security in such a way that it will align with their business goals. Up until the breach, the leadership at Rekt assumed they were secure because they were compliant with MICS regulations.
This scenario can be viewed from a few different perspectives:
- A current business leader now charged with the information security program
- A new security leader coming into assist with the recovery
- A consultant coming in to assist the casino with the recovery
Whichever perspective you choose, a plan needs to be developed to better secure the casino, but where you do start when things have gone really wrong? Deciding where to start is daunting and it’s easy to develop analysis paralysis.
My goal with this blog post is to help develop an approach for creating or improving an information security program after the breach has occurred.
On the he positive side, this scenario can be viewed as an “unscheduled penetration test” based on a real threat, with actual techniques, and you know what the real impact is. Ordinarily, you might run tabletops, step through the incident response, and BCP/DR process based on some hypothetical actions and results. In this scenario you have real results that justify your business case.
If you happened to be there during the incident, the actions taken by the IT team can give you valuable clues as to the state and maturity of the information security program.
For example:
BCP/DR
If the casino has a BCP/DR plan you would expect to see it activated and assets being brought online while the incident is being worked. However, that wasn’t the case at Rekt Casino. The three IT technicians were simultaneously scrambling to get systems back online while negotiating with the attacker for the ransom.
Communications
You would also observe the communications between the IT team members and the business leaders at the casino. Ideally, there should be regular updates and expectations should be well managed.
During the incident at Rekt Casino there was little communication from the IT team working the incident. They were siloed and there were no lateral communications between the team, the other areas of the casino, or to the business leaders. The rumor mill started to churn out wild conspiracy theories that soon spread all over town.
The only real communications during the incident was a back-channel conversation between one of the IT team members and a friend, that was a seasoned incident responder, helping them out while she was on vacation.
Policies and Procedure
If Rekt Casino had basic policies, procedures, and supporting documentation that aligned with those, you would hope to see things such as:
- A functional call list for executives, board members, employees, and vendors.
- How to proceed with contacting law enforcement and a relationship already in place.
- Administrative controls that could have prevented the incident.
- How to handle an incident, specifically if the philosophy is contain and clear, or watch and learn.
- Network diagrams, configuration information, change documentation, and exception requests.
Rekt casino didn’t have any of this in place. This had been discussed many times at board meetings over the years, but it was never a priority. The business leaders didn’t think Rekt casino was a viable target. There were bigger casinos around, and they didn’t feel like the gaming industry as a whole was a target for attackers.
That stance also informs you about their overall security awareness. Just a few years previous, a large casino was attacked by a nation state and was taken completely offline. The story was in the headlines for weeks, but somehow the executives and
board members of Rekt were completely oblivious.
Backups
In ransomware incidents the one thing that can save the day is good backups. Organizations with a solid security program have backups and snapshots that are at least tested monthly. Rekt was backing up their data to disk on the same servers that were affected by the ransomware.
They also took an end-of-month backup off site, but that data was for historical purposes and not recovery purposes. There were some key files recently sent over email, but even the local email files were encrypted on the affected machines. Rekt is really in a bad spot with this incident.
As you can tell, things were going really bad for Rekt Casino. One of the board members recalled reading about a recent breach where the organization called an incident response team to assist with the containment and recovery. The board member reached out to that firm to help with Rekt casino.
Incident Responders
The incident response team arrived on the scene approximately 28 hours after they were contacted. The reason for the long delay was that Rekt didn’t have an expedited procedure in place to get approval for the incident responders.
Each one of the incident responders had to pass a background check and be approved by the Nevada Gaming Commission before they were allowed access outside the publicly available areas.
The incident responders started their investigation and observed the following:
- The incident responders started by reviewing firewall logs and found multiple connections from the network to IP addresses in another country over port 6500. Packet captures showed that those connections were encrypted.
This observation was assumed to be malicious since there was no supporting documentation indicating it was normal traffic. In fact, there was no network flow documentation at all. - The email server was hosted on site and had no log retention policy, anti-spam, or malware countermeasures.
- Memory dumps revealed the ransomware executables running in memory, along with psexec, Power Shell, and an unknown executable.
- A review of the event logs of affected systems showed remote desktop session from various other systems using the domain administrator account after hours for the previous 3 weeks
- There was no centralized logging for the network devices such as routers, switches.
- The endpoint protection was a signature based anti-virus that had an expired license and was receiving no updates.
The incident responders confirmed that ransomware was utilized in the attack and contained the affected systems.
All the servers were offline, the majority of the workstations were offline, and the only road to recovery was reinstalling the operating systems and restoring the data that could be salvaged. The fear of a root kit was on everyone’s mind, simply scanning and putting the machines back into production was not an option.
Post-Mortem
The time has come to start securing the network, recovering, and laying the foundation for the security program. Other than your own observations, you’ll want to take a look at the incident report, and in particular the post-mortem or lesson lessons learned section.
This section will answer some key questions such as:
- How did this happen?
- Why did this happen?
- Who did this?
- How can this be prevented from happening again?
The answers to those questions will help inform the immediate steps you need to take after the breach/incident.
The high-level findings of the incident are as follows:
- Rekt Casino suffered a ransomware incident.
- The systems became nonresponsive over a holiday weekend.
- All servers and live workstations were affected by the ransomware.
- Triage forensics and memory forensics show evidence of Powershell, PSexec, and the ransomware executables.
- The firewall logs show outbound connections to a foreign country. Packet captures were taken, but the connections were encrypted.
- The email server has been in production for more than 10 years and has limited countermeasures for spam or malware.
- The endpoint protection is signature based with an expired license.
- The firewall was a basic port filtering firewall with no outbound rules. All outbound connections were allowed.
- The attacker compromised the domain administrator account and was able to move laterally throughout the network.
There was little evidence to identify the attacker, or how the malware entered the network. In situations like this, you might be able to get an idea based on publicly available research or threat intelligence.
You must be cautious with threat intelligence. Attackers can change their tactics, techniques and procedures quickly. They can also change their indicators of compromise and frequently do. A good reference for this is the MITRE ATT&CK framework and the Pyramid of Pain.
In this scenario, publicly available researched showed that this particular strain of ransomware has been delivered over email in other breaches. We will assume that’s how it compromised the systems at Rekt Casino.
If the publicly available researched had shown the typical point of entry was over a USB drive inserted into a workstation or server, that would change our initial steps on implementing the new information security program.
You might be pressured to determined who’s to blame. The best answer to this question, and honestly the most correct one, is that the cause of a breach is due to a break down in policy and procedure.
Don’t get caught up in the blame game, it’s not productive, it can create an adversarial atmosphere where you need the support and cooperation of all those involved.
This is Part I of a 3-part blog series based on SANS MTG514: Security Strategy, Policy, and Leadership.
Read Part II here. Read Part III here.
About the Author
Joe Sullivan has over 20 years of experience in information security. Joe is Principal Consultant at Rural Sourcing in Oklahoma City where he manages and develops the security consulting services and the teams that provide them. Over his career Joe has worked in incident response, penetration testing, systems administration, network architecture, forensics, and is a private investigator specializing in computer crime investigations. Joe teaches MGT514: Security Strategic Planning, Policy, and Leadership. Read more about Joe here.
