Desert Sands Case Study Report

This compromise occurred through a group of Iranians wanting to get back at the Sands owner/investor. They spent a lot of time trying to break into the Sands network and after a few days were able to find a test web application to get in, but it still took a few more days to get the right credentials to go from the Bethlehem location to the Las Vegas location. I believe that these attackers were too determined, and it would have taken a lot for them to stop and feel defeated. I also think that if the vulnerability they found was fixed that they would have still found a different vulnerability to get into the Sands network somehow.

If I was working for a company in the U.S., then I really hope I would be reaching out to law enforcement if an attack like this occurred to my company. Otherwise, we would also be breaking the law by not reporting the incident. Users’ and customers’ personal information and credit card data had been compromised. At least in that aspect, we would need to report that to law enforcement and make sure the compromised users are made aware. However, if we had a good idea that the attacker was a nation state, I would not be reaching out to law enforcement to help with the matter of helping the company or holding the attackers accountable. There is a political battle that would most likely turn violent or into a disastrous cyber warfare that the US is not prepared for if law enforcement tried to hold another nation state accountable for a cyber-attack.

The end of the article discusses how law enforcement would not go after the nation state responsible for the attack and that there has been many discussions of if the government or business should have the ability to fight back. I don’t think that I agree with this, at least with my current knowledge. I believe right now some companies can barely even defend themselves let alone go on the offensive. I don’t think an organization can fully defend against a nation state attack. I think the organization can only prepare for an eventual attack, which is following best practices like defense in depth, updating technologies and hardware, following security policies, and training employees on security. I don’t think it is worthwhile to prepare beyond those steps or in a similar vein. If the company I work for is within a malicious nation, there may be more that local law enforcement can do to help the company going through the attack. I think that if the company may want to befriend the government in a way to avoid being considered a threat by a hacktivist group of that nation.

References

Elgin, Ben, and Michael Riley. “Now at the Sands Casino: An Iranian Hacker in Every Server.” ​Bloomberg.com,​ Bloomberg, 12 Dec. 2014, 3:48PM, www.bloomberg.com/news/articles/2014-12-11/iranian-hackers-hit-sheldon-adelsons-sa nds-casino-in-las-vegas.

NASA Case Study

I believe that if NASA had been responsible for the maintenance of the system, they would have written a similar report. I did further digging into reports the Inspector General for NASA has released and overall they seem to be objective and almost like a third party. However, even with seeing these reports, I still have some skepticism that there exists some internal pressure to not completely convey NASA as incompetent or in a more than manageable negative light. Even if NASA were to put forward a report where they were at fault it would most likely be more geared to what they were doing well and include plans of how they aim to resolve the findings. Whereas, in the Cybersecurity Management and Oversight at the Jet Propulsion Laboratory, the Inspector General report creates a negative appearance of JPL and a negligence on their end putting complete fault onto their operations.

Due to there being many major findings that NASA found with JPL, there are many approaches that JPL could take to remediate their issues; however, many will take time to implement and change culture.

For incomplete inventory, this is something that many companies struggle with, but is probably the most important step. If the company does not know what devices it has on its network, then there is no way they can sufficiently defend the network. This can be remedied by using a third party software that collects identifying features of the devices and aggregates them into a single pane of glass.

For segmentation of a network, many companies also struggle with concept as well. There are many companies that have a flat network and once a device connects, it could potentially see everything else connected to that network. One way to remedy this would be to have completely separate networks for the different partner environments. This would allow for devices within certain networks to only see ones that it should. Devices should go through an approval process and require authentication to be on the specific network.

In terms of patching, many companies face this as a culture issue. The best way to combat this is to talk to leadership in different ways that highlight the level of importance patching is. Usually this will include dollar amounts of downtime for patching and potential loss time and money if a vulnerability was exploited due to not patching.

Policy should match practice for accountability and ability to audit the company’s processes. Without policies as an enforcer, the entire company could turn to chaos as some issues may be overlooked or forgotten. Additionally, promises to customers may include these policies and staying in accordance to them. Any falter could be a liability and cause for the other company to sue.

Reference

Final Report – IG-19-022 – Cybersecurity Management and Oversight at the Jet Propulsion Laboratory, Report No. IG-19-022, Office of Inspector General

Target Case Study

Incident detection and response can allow for fast finding and triage of events to determine if there is malicious intent behind certain actions that take place on the network. When corporations work with third party vendors or acquire attributes of other businesses, there must exist some level of agreement to cooperate between the businesses. Some companies are able to respond better to incidents due to many factors and this should be taken into account when agreeing to work together. There should be some written agreement between the companies as to what access will be given to the different companies or reporting.

So for an acquisition, there may be some agreement that the company acquiring will be able to have visibility into the other company’s network and devices on the network. However, many third party agreements do not have integration between the networks, so instead there may be requirements that the company must report to each other known incidents they find or there Intrusion Detection System (IDS) must have certain levels met or response times to alerts. Business partners must have a defined agreement to be able to trust these partners as to not be attack vectors and also have a value of image, if one is compromised then the other may be pulled in whether it was actually their side or not.

I do not believe that small businesses must have a mature cyber incident detection and response capabilities within their own organization. However, I am of the opinion that if small companies want to work with these large companies that they should have some form of incident response that allows for finding potential compromises in their network, whether internal or third party. Then they should agree to having the compromise fixed and reporting that to the larger company. Additionally, the larger company should have some way to support the smaller company if requested and denoted in their contract of agreement. I believe that cyber is an area that changes rapidly and many small businesses cannot afford to have a full team dedicated to this area. However, these smaller companies still need to have something in place to account for these potential breaches.

References

United States Senate Committee on Commerce, Science, Transportation.​ A “Kill Chain” Analysis of the 2013 Target Data Breach.​ 2014

City of Atlanta & NotPetya Case Study

Paying a ransom for a ransomware attack can be a difficult situation for many companies. Attackers want to get the most money out of the company they are attacking, but have the ransom be placed at a price and appear not to be taxing. The path of paying the attacker’s ransom is usually not recommended by professionals in the cybersecurity field as the attacker may be deceptive and not fully release the data if at all. Also, the vulnerability of how the attacker invaded the network still needs investigating and patching, therefore another attack through the same entry point does not occur again. Further, companies need to consider how replaceable their data is. Do they have a non-infected hot site that the data can be pulled from? These companies should be considering these different aspects when making the decision to pay the ransom.

Many cybersecurity professionals do not recommend paying attacker’s ransom for many reasons. The main reason is that there is no guarantee that the attacker will follow through with releasing the data. The attacker may also encrypt the data and once released is still unusable to the company. There may be an additional ransom for decrypting the data. Additionally, many professionals may see that in their day to day that security is overlooked as a necessity for the organization and they may want to use this opportunity to get their system up and running again but also to make it more secure. There can now be an incentive to defend the company network, keep patches up to date, and everything else that goes along with better defending the company from another cyber attack.

Even in the case where there is data compromised, not just locked; data is stolen and threatened to be released. I would argue that the data is already compromised and will most likely be sold whether the ransom is paid or not so the company should not pay the ransom and instead focus on data privacy and account compromise/recovery procedures.

Overall, the only case where I would agree to pay something is if the price was relatively reasonable, which “reasonable” would be up for debate depending on the attack, and there was absolutely necessity as in there is barely anything running or some kind of dire state.

The best way to prepare for a ransomware attack is to have back up data, continual scanning for vulnerabilities, and have procedures in place for responding when the attack occurs. With having secure backup data, then the company can revert with minimal downtime. By having scanning on the network and entry points, vulnerabilities can be fixed to lower the chance of one being used to enter the system. Finally, by having procedures in place for detection, the company can be alerted to the compromise quickly to contain spread and to remediate for short downtime.

References

https://www.sophos.com/en-us/medialibrary/PDFs/technical-papers/SamSam-ransomware-chooses-Its-ta rgets-carefully-wpna.pdf?la=en%E2%80%8B https://web.archive.org/web/20210107050233/https://www.wired.com/story/notpetya-cyberattack-ukraine-r ussia-code-crashed-the-world/ https://www.wired.com/story/atlanta-spent-26m-recover-from-ransomware-scare/

Equifax Case Study Report

Overall, I believe that Equifax did execute an effective incident response effort. Equifax has procedures in place that once informed of a potential vulnerability, they executed vulnerability scanning to determine if any machines internal to their network needed to be patched. Although their scanning was flawed and did not find the vulnerable systems, they still performed scans that should have found them. This aligns with the preparation portion. Then with the detection and analysis, their IDS was misconfigured, but they eventually got themselves together to be able to detect the breach. Once found they performed containment and eradication efficiently. They also had some good ideas of developing a website for the breach and a dedicated call center for post activity, but were unsuccessful in their effectiveness. Including an outside company, Mandiant, to perform an analysis was smart to make sure there was agreement about what occurred.

Knowing that money is a large factor, and not much is given to security, I think the biggest flaw that occurred with Equifax was that their security certificate that was monitoring the ACIS network had been expired for the 19 months leading up to finding the suspicious activity. Having working security features in place is one of the most important things to implement. If things are not implemented correctly, then analysts are not getting all the data that can help them determine suspicious activity and activity can be missed.

I know the topic of CISO placement is relatively controversial. I have been in a company where a CISO is under the CIO and another company where the CISO is also the CIO and is under legal and I see the pros and cons for each. However, I think overall, it depends on the company. Where the company is information driven, I think it makes sense to have the security teams more closely aligned with the IT and information teams. This allows for more collaboration of understanding the networks and patching the systems. In my current role, I fall under a product security team for aviation. We are not a typical network detection team, so it does make sense for us to fall under the legal team as we need to have more collaboration with making sure the products align with any regulations. I think that no matter where the CISO is, whether he is directly under the CEO or not, the CISO should have the ability to call and inform the CEO if there is any major event, that is the biggest take away in organizational structure. There should be a culture that exists where it is okay for the CISO to report up the chain, but also directly to the CEO.

Stuxnet Case Study Report

If I were designing security for Natanz, I would recommend many things in order to have defense in depth. I would want to implement a network prevention and detection firewall. This would allow for easily blacklisting or whitelisting IP addresses and certain ports. Additionally, I would recommend having an Endpoint Detection and Response (EDR) software implemented on all devices connecting to the internal network to allow for monitoring activity of potential unauthorized or malicious files running. I would also recommend they have a Security Information Event Management Tool (SIEM) in place to collect the logs from the network traffic and the EDR. This will allow a team to observe and have quick response if anything unusual is detected in the environment.

I believe that having an air-gapped system may still be beneficial in some situations. In cases where data should be completely offline from other things this is the best solution. However this would be a very rare case in my opinion. An example would be when writing or testing malware, a team would most likely want to be working in an air grabbed network to avoid the potential infection of other devices.

If a system is not air-gapped and is connected to the internet, then that means there is at least one device that can reach out to through the internet and in turn someone can reach in. I would argue that not being air-gapped is more likely to have a potential breach or attack occur.
I think the best way to detect a compromise of an air-gapped environment would be to have software similar to an EDR installed on each device, however there would need to be a human to check physically on each of the networks to check the EDR to see if there was any attempt of unusual activity on any of the devices. So this wouldn’t allow for a real-time response unless there was a person sitting watching the software constantly.

Usually there is not much a vendor can do to prepare for zero-day attacks. However, I would argue that because these attacks used for Stuxnet were all published before use that Microsoft should have been aware of them. I believe that companies should have a threat hunt team/ person. Part of this team’s role or doled out to a third party, should be to search in publications for compromises that may affect their systems.

References

https://en.wikipedia.org/wiki/Air_gap_%28networking%29#:~:text=Air%20gap%20%28networking%29%20An%20air%20gap%2C%20air%20wall,public%20Internet%20or%20an%20unsecured %20local%20area%20network​.

https://www.wired.com/2011/07/how-digital-detectives-deciphered-stuxnet/ https://spectrum.ieee.org/telecom/security/the-real-story-of-stuxnet

Yahoo Incident Case Study

The breach against Yahoo!, included exposing “the usernames, email addresses, phone numbers, birthdates, passwords and security questions/answers for at least 500 million Yahoo accounts” (NLR). This many accounts is a significant exposure and part of the reason the breach was hidden and minimal users were notified.

The company was fined $35 million from the SEC and $80 million from federal class action settlement (NLR). While these are significant amounts of money, I think this is a fair amount. The company was in an interesting place of knowing if they notified users that they would lose customers, but also risked that revenue in the interim and then later getting fined. I’m not sure fines will necessarily ever be effective until they become a large portion of a companies annual revenue, otherwise, they will always just be a slap on the wrist. I think there also needs to be more than fines to hold companies accountable. These types of issues are slowly being addressed in legislation like GDPR and the California Privacy Protection Act.

I do believe that Yahoo! Intentionally tried to cover up the breach. I think the sole fact that the company did not mass contact and inform it’s users of the breach shows that they were trying to hide what was occurring. The company notified 6 people of the millions of the breach. The National Law Review article states how the fines given to Yahoo! were the first time fines have been given to companies due to cyber attacks.This has been a continuing trend with the FTC holding companies accountable for breaches and privacy in general. In addition to fines, the FTC has been able to hold companies accountable for creating and maintaining security response teams.

I believe that Yahoo’s initial decision to not focus password resets was a significant mistake on their part. During the investigation process of determining if a breach has occurred or accounts have been compromised, resetting passwords is usually always a part of that process. Sometimes this is even just a good measure in the process, a “just-in-case”, try to reduce the possibility of if it is undetermined if the account was compromised, then at least a password reset reduces the chance that an attacker will be able to get in again. In this case where Yahoo! knew there were compromised accounts and stolen passwords and still did not force password resets is the epitome of a company not doing their due diligence and potential furthering their users to compromise; like if users use that same account information for other platforms.

References

https://www.natlawreview.com/article/hacked-hacker-hire-lessons-yahoo-data-breaches-so-far https://techcrunch.com/2018/09/06/alex-stamos-facebook-yahoo-security-officer/ https://fortune.com/2016/12/19/yahoo-hack-cyber-security/

Example Cybersecurity Incident Report

Executive Summary

Timeline

On <date>, the SOC received notice from the Network Team about unusual behavior on the internal network. Upon further investigation, the SOC found successful logins after multiple brute force attempts. The SOC determined that there was malware present on the system to create a backdoor. A backdoor allows for unauthorized personnel to easily get back onto the network. After finding this malware, on <date> the internal website development team was authorized to revert the corrupted file to remove the malware.

There were multiple brute force attempted logins initially. Some of the successful logins were able to update the file in question.

TimestampIP AddressAction
06/Dec/2016:17:29:13 -0500
199.168.99.18

Brute force successful login
06/Dec/2016:1729:17 -0500
199.168.99.18

Update to the file
07/Dec/2016:11:13:22 -0500
199.168.99.18

Brute force successful login
07/Dec/2016:11:13:23 -0500
199.168.99.18

Brute force successful login
09/Dec/2016:12:30:41 -0500
142.54.189.162

Brute force successful login
09/Dec/2016:04:18:40 -0500
142.54.189.162

Update to the file
10/Dec/2016:05:00:00 -0500
142.54.189.162

Brute force successful login
10/Dec/2016:05:00:00 -0500
142.54.189.162

Update to the file
10/Dec/2016:05:00:00 -0500N/ANetwork team notifies SOC of the unusual behavior
10/Dec/2016:05:30:00 -0500N/ASOC begins investigation into logs
10/Dec/2016:14:15:00 -0500N/ASOC identifies the malicious code in the file
10/Dec/2016:15:00:00 -0500N/AThe network team receives approval for removing the infected server off the network.
11/Dec/2016:04:45:00 -0500N/AThe website development team reverts the infected file removing the malware from a version of the file from before December 6th, 2016.

Actions Taken

The SOC found the file with malware through searching the network logs. The network team removed the server hosting the infected file off of the network until restoration could commence.

The website development team took the action to restore the compromised file to a version before the first change by an unauthorized user. Then, the network team was able to place the server back online.

Based on external IP reporting tools, the IPs that successfully logged in after brute force attempts are not known blacklisted IPs. Therefore, the SOC believes these IPs are a part of a botnet, but not themselves malicious and will not be blacklisted from the network.

Financial Impact

Below is a table representing the costs associated with this incident.

ItemCost
Lost Revenue (1)
$560,000
Server Downtime for Restoration (2)
$140,000
Labor of Investigation (3)
$36,000
Total
$736,000

1 Loss of revenue is calculated by lost productivity for users and customers. This is done through average users in an hour over the timeframe the server was down (400/hour) and a flat rate of $100 per hour for productivity of customers/users. (400 x $100 x 14 hours)

2 Downtime cost is determined by a flat rate of $10,000 per hour that the server is down. The server was taken off the network for restoration for 14 hours.

3 Labor is determined through the average wage of investigators and the amount of time they worked the investigation. $45(average wage) x 20(number of investigators) x 48(number of hours worked)

Lessons Learned – Successes

  • The internal teams were able to coordinate an effective investigation and implement proper responses.
  • The Network team was able to identify the issue and alert the right parties to continue to investigate further.
  • The SOC was able to use purchased tools to determine the issue and work with the website development team to remediate.

Opportunities for Improvement

The following improvements will be tracked through JIRA to ensure completion.

Issue:​ The SOC was unable to identify the successful logins by the IPs brute force attacking. Recommendation:​ The SOC shall implement a new alert that will fire if a successful login occurs after over 5 failed logins. Additionally, the team will develop a playbook with this alert to allow team members to learn what steps to take when this alert fires. Action Item Owner: ​The SOC Manager

Issue:​ The SOC was unable to identify the successful logins by the IPs brute force attacking. Recommendation:​ The SOC team will develop a playbook with this alert to allow team members to learn what steps to take when this alert fires.
Action Item Owner: ​The SOC Manager

Issue:​ There was no immediate server backup to revert the system immediately. Recommendation:​ There should be hot and cold sites developed to have older versions of the files ready to take over when an issue arises to allow for less downtime.
Action Item Owner: ​The Network Team Manager

References

https://www.malwarebytes.com/backdoor/#:~:text=A%20backdoor%20refers%20to%20any,syst em%2C%20network%20or%20software%20application​.

https://github.com/bediger4000/php-malware-analysis/blob/master/backdoors/91.200.12.9-2018 -03-04a/README.md