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.